Active forks?

[JimmyCushnie]

Recently, the lovely Michael Lidgren added the following line to this project's readme:

Note! Not actively developed any more; only accepting trivial or minor bug fixes.

And this is certainly true, with dozens of issues and pull requests going unaddressed for years. (To be clear, I hold no ill will towards Michael for this; I totally respect his decision to move on from this project.)

And hence, my question: are there any forks of Lidgren that are in active development? Is there a place for the Lidgren community to contribute major fixes and new features?

If so, I think a link to that fork should be added to this project's readme. If not, someone more netcode-savvy than I should start one.

[PJB3005]

Our game engine uses Lidgren and has had various changes made to it (e.g. Span<T>). I did try to upstream some of it but my last few PRs haven't been responded to yet so I haven't bothered to do the rest.

Source here: https://github.com/space-wizards/RobustToolbox/tree/master/Lidgren.Network

[PJB3005]

I should note that because we haven't been very organized and Lidgren in our repo is a copy without proper history preserved. I'm down with doing proper forking and using a submodule instead so it's easier to consume for others.

[JimmyCushnie]

Those look like some great changes. I would very much appreciate a proper fork version, so it's easier to view the diff compared to upstream, and to merge changes I like into our personal fork.

[PJB3005]

I've gotten started on it and am moving stuff over. I'm also taking the liberty to clean up stuff like the unit test project.

https://github.com/space-wizards/lidgren-network-gen3/

[JimmyCushnie]

Fantastic, I will be watching your fork with great interest.

I encourage you to wipe the readme and use it to explain why you made fork and what the differences are from upstream.

[TechPizzaDev]

https://github.com/TechnologicalPizza/lidgren-network-gen3
Active fork but is really striving away from the original. Similar to space-wizards fork (Span support, bugfixes, allocation improvements) but includes many API and internal changes making it incompatible with the original.
A feature I'm currently developing is NetStream (Stream over NetConnection with read/write/seek) including a NetMessageScheduler to allow for dynamic message priorities.

The only .NET version I'm supporting is Core3.1, and I'm moving to .NET5 when it launches.
Just posting here to provide some extra code for thought :)

[ThomasMiz]

https://github.com/TechnologicalPizza/lidgren-network-gen3
Active fork but is really striving away from the original. Similar to space-wizards fork (Span support, bugfixes, allocation improvements) but includes many API and internal changes making it incompatible with the original.
A feature I'm currently developing is NetStream (Stream over NetConnection with read/write/seek) including a NetMessageScheduler to allow for dynamic message priorities.

The only .NET version I'm supporting is Core3.1, and I'm moving to .NET5 when it launches.
Just posting here to provide some extra code for thought :)

I like where @TechnologicalPizza 's fork is going, maybe it would be wise to try to work on the same repository to better keep the project going.

Until then I'll be using pizza's fork. It would be nice if they enabled Issues on the repo just in case :)

[TechPizzaDev]

@ThomasMiz Opened up issues on my fork. Don't even remember why I disabled them 😃

[ThomasMiz]

@ThomasMiz Opened up issues on my fork. Don't even remember why I disabled them 😃

I like that you're going full on with post-framework technologies, focusing on targeting .NET 5 and updating the library to use the newer technologies. You've enabled nullable types and I've even seen some small stackallocs to reduce GC pressure!

Since I'm also going with full .NET 5 this is really a plus to have 😄

[TechPizzaDev]

Oh yea, I really love new stuff. I'm trying to make everything as user-friendly as possible. Have even considered making every message a Stream that is sent on the fly, so memory could be a problem of the past if you have progressive parsing ⭐

[PJB3005]

The reason I didn't go full out on dropping old Framework support for our fork was that Unity is still using ancient .NET versions (not even NS2.1...) . Believe me I would love to drop support for .NET Standard and just go full .NET 5 100% but I imagine Unity users would still be interested as well. (Still adding .NET 5 specific features like Half support where applicable though)

Have even considered making every message a Stream that is sent on the fly

I would hope that would be optional without affecting performance elsewhere if not used because that sounds like it kind of defeats the purpose of UDP entirely.

[TechPizzaDev]

It would be an improvement compared to needing the full message in memory though and by that give better performance.
I plan that messages will come in synchronously based on their channel.
The only difference from the current design is that you would have partial access to the message that is currently in transit on the specified channel.
This would be tightly integrated so you would barely notice a difference in typical consumption of messages.

[PJB3005]

Ah, for receiving I can see it making sense yeah. I was imagining this sender side which wouldn't be very practical (it ends up in a queue at the end of the day anyways due to the architecture).