Securing Urho3D's future


Awesome, I believe I may be of some assistance.
Thanks for the issues link - that’s where I need to start!

I’ve recently moved from Windows to Linux, and it’s been decades since I touched a Unix-based OS, so I am on the back foot, and especially with regard to my toolchain - looking forward to contributing!


Ugh, I got off to a bad start :frowning:
Today I patched issue #2352, then set up a github fork, uploaded my changed files ready to issue a pull request, and discovered that my project files, and the issue itself, were redundant.
Somebody needs to update the archive download links on the homepage (maybe just redirect to github master?), and curate the Open Issues for redundancy with respect to any wholesale changes that have occurred over the past year (such as the network system being replaced).

I’ll bring my files up to date now, and then take another look at the Issues :slight_smile:


With the latest files pulled from the github master, I see that the problem in Networking still exists.
Essentially, the problem is that the Connection class is gathering the IDs of dirty nodes in an UNORDERED CONTAINER (HashSet) … this means that Clients can recreate nodes in a different order than that in which they were gathered, which spells trouble for reconstructing the node parenting. I believe the remedy is simple - change the container type for HashSet nodesToProcess_ to instead use Vector, which is an ORDERED container. This subtle change requires changes to several other files, and though I did not test the use-case of complex node structures being reconstructed out of order, it did compile very easily, and appears not to affect anything else. If I get time tonight, I’ll port the changes back in, and issue a Pull Request.


14 posts were split to a new topic: P2P Multiplayer