|
|
I'm attempting to add the image attachments, now. Note these are the test clients, *not* the game. router-snip.png (100,530 bytes) |
|
|
I should note that I have not attempted a packet capture to confirm the game is even attempting to request a port forward. Discovery of my external address works. I have a dual-stack (IPv4 and IPv6) network and both protocols are functional. I do not have another player to see what, if any, effect having a client in the mix is. I wouldn't expect that to help, as the router doesn't see a UPnP redirection request so there's nothing to connect to without manual forwarding. The test clients shown in use are those from the `miniupnp` and `libnatpmp` projects. |
|
|
There's not anything I can particularly do about this. LiteNetLib is not maintained by us, nor do I understand the code of it. It's open source middleware, and one of three networking solutions we provide. They say they do certain things, and it has worked for a variety of users (aka, we have users who have not had to port forward, and had it work properly). Beyond that, as the lead network programmer on the game, there's not a lot more I can do other than throw my hands up. My specialty is the game logic layer, not the network layer, which is why we use various middleware. It seems to work for some people reliably, and not for others, and I don't have the expertise to know why that is. If it doesn't work on your setup, then port forwarding or a different solution would be the way to go. I know that this is really not the response you would be hoping for, but the nat punchthrough is a third party "wow that's nice to have, hope it works" feature from our perspective. Nice when it works, but it's not a core part of the work we did for multiplayer for this game. I suspect you know a lot more about this subject than I do, to be honest, as it's not a part of the network layer that I've focused much on. The network layer of the game is open source in a way that modders are able to add entirely new transport layers, or make additions or changes or replacements to existing ones. I set things up that way so that if new cool technologies emerged in the future that someone wanted to use, that would be possible to add in with relative ease if they know the transport layer and want to put in the time. For my part, I unfortunately don't have the time or ability to chase that sort of new middleware for this myself, as this game was a money black hole (it's still like $400k more that the game would have to earn before the first dollar of profit, ouch, and it's not going to ever earn that). So while we do fix material defects in the core game itself, and there's a vibrant community of modders and volunteers updating things out of love for the game, this sort of addition is way out of scope for me. Sorry about the trouble you had with mantis losing your first report, and I don't mind the terseness. I wish I could have given you a better response, myself, but I figured I would at least give you a "complete" response that kind of explains where I'm coming from and why, and what the modder options are at least. |
|
|
Totally fair and understandable, Chris! I definitely appreciate the full answer. I'm sad to hear the project is still in the hole, despite the love that's clearly gone into it. I looked around on the wiki for any information about modding the transport layers (to get an impression of how much work I'd have ahead of me if I did try to tackle it). This part doesn't seem to be documented or something other modders have tried to do? In the case that I *do* try to make a go of it, what sort of license on my code would be most appropriate/useful to players (and yourself?) If I use another library or bindings to do so from another language, what sorts of licenses would be allowable/preferable, in the (unlikely) case I manage to do it well? |
|
|
Cheers, Paul -- thanks for the understanding. This particular game was likely always going to stay in the hole, it was pretty clear from about 2021 onward, possibly 2020. That said, it certainly was a good amount of capital investment in tech in other respects, so it is helping us in terms of developing the new Heart of the Machine title faster than we otherwise would have been able to. For the network layers, nobody ever showed any interest in modding those, really, so I didn't ever really document it. However, the good news is that it's very very simple. There are two overall parts: First part, you need to declare your networking library in xml. I don't have it open in front of me right now, so I don't recall the exact folder name, but it's something like NetworkingFrameworks or something, and the actual details of the entries are pretty self explanatory. One of the main things, though, is that this links to a dll and a class name, which are going to be dynamically loaded at runtime. So this is the hook into what would be your code. LiteNetLib is set up exactly this way, so you can copy what it does. The Steam and GOG networking works a "special" way because it has to hook into their embedded libraries, so ignore those for your purposes. Second part, you need to create your dll, which should be .NET 4.7.2, or similar, ideally. Definitely not into the .NET 5 range. There is an ArcenNetworkLibrary solution in the CodeOther folder (I think those ar the names -- I am doing this from memory). It would be good for you to copy the entire folder of that solution/project, and just rename it as you wish. When you open that solution, you'll see a single project with not a lot in it. The first part that is there is some form of ArcenSocket, basically that's the base class that the primary controller class inherits from. This includes various things like "open a connection to a server" or "listen for connections from clients" to "send a batch of data to the server on a given channel" or vice versa for the client. The names of the methods are all very explicit in terms of making clear what they do. The rest of what is going on in that dll is all just LiteNetLib itself. That is just packed right into that same dll (this is very much the simplest way to do it, versus having a dll linking to another dll, as that may not work right). The code in the ArcenSocket descendant just basically translates what the game wants into what LiteNetLib expects, and it's a pretty thin wrapper. Everything else is just LiteNetLib itself. So for your purposes, if you were doing a different framework entirely, then you'd strip out litenetlib, put in whatever the other library was, and then adapt your new ArcenSocket descendant to point to that properly and use it. Based on my experience with networking libraries in the past, most likely it should be pretty darn similar to what I've already coded there, which is nice. If you were going to use a newer version of litenetlib (if there is one), then you might just delete the old and import the new. I think I made a few minor efficiency improvements to the current build of litenetlib in the game, but I can't remember for sure. It would have been something basic like not wasting extra buffers or something. If you were going to use the exact same version of litenetlib, but put in some new code on the OpenAsServer code, then it gets even easier. Essentially, I've seen various tools that try to do [things] when opening that port, and if you've imported a new library that does those things but then hands it over to LiteNetLib, then that's a very low surface area. My personal main challenge with it is that I'm not well versed in those [things] that they do to try to bypass NAT, and testing those takes a lot of time. And the version that's in LiteNetLib happens to work with my router, which doesn't help matters. You'll find that the CodeOther folder is just included with the game directly, and that part of the game is one of the several parts that is fully open source. I think that LiteNetLib itself is MIT license, but anything that is permissive enough for us to include it uncompiled that way is great if you want us to also distribute these to other people. Given this is sitting perfectly open source next to the main application rather than being embedded in it, I think even the GNU licenses are okay, but I can't remember for sure. It is possible to package this all as a literal mod -- see how many of them include both custom xml and dlls -- but this is one of those rare cases where it might be easier for users to just distribute it as part of the main game package and just say in the description "hi this particular framework is a modded one if you try it, no support from arcen," since there is already that opt-in step of choosing the framework. Having a second opt-in step at the normal mods screen would probably be a hassle for end users. But I'm fine with whatever. Whatever libraries you use should ideally be in native C#, version 6.0 or less. You might have some luck with some 7.x features, but anything higher than that won't compile right. If you try to link against something from C++ (or objective C or whatever), that gets very very complex because firstly that will only work on windows (or OSX for objective C) and other people on other OSes will be sad, and secondly you have to link against that "native" dll from your custom dll in a way that is... challenging. It involves using the plugins folder, which is different for each OS, and it's a real pain. This is how the Steam and GOG linkages are handled, as they are C++, and it's really really not something you want to try. There are a lot of various tools for C# natively, and its basic sockets implementation is extremely low-level as it is. And it's OS-agnostic. There's not really a reason to move to another language unless the functionality is just plain not in C#, and you're okay with the rest of the world of pain that comes with that. In the event that LiteNetLib is "fine, once connected" from your pov, and it's really just about the initial connection, I know there are various C# pieces of software that do [things] to try to broker that port forwarding with the router. What I don't really understand is how they would integrate with the ongoing connection that LiteNetLib has, and I don't have a good way to test them, etc. It's also possible a newer version of LiteNetLib exists which solves all the problems; I really don't know. If you think that ongoing connection stuff also needs work, then swap out litenetlib, but otherwise it's not really required. If you do decide to look into this and feel like the full source code repository access would be helpful, let me know. A lot of the more active (or deep-diving) modders have that sort of access, as it just makes things easier. Factorio dev does the same thing, I was glad to learn. None of that includes any expectations of anything, gaining access is not a guarantee you definitely would do something. It's all up to you. Cheers! |
- Anonymous
