I understand you'd rather I use C++ code. I'm not famillar with C++ actually, so I'll probably not do anymore with this diff.

In D2432#102349, @Stan wrote:

Just for the record, only debian seems to provide a man command.

In D4283#182511, @Stan wrote:

Did you see https://code.wildfiregames.com/D2432

This obviously isn't finished yet. I wanted to get some feedback before I proceeded.

Sure. I'm currently building the game+developing this patch from the github mirror. What would "adding this option to atlas" involve?

Me and @Jammyjamjamman just tested it with an Internet game; no problems.

I didn't get any warnings or errors while patching.

imo, I don't really see any value in having periods at the ends of all these incomplete sentences.

My bad.. he ran make clean before re-compiling but didn't run clean-workspaces.sh. Doing so now.. I'll update here shortly.

In D2745#121607, @andy5995 wrote:

My friend who is using Manjaro 20, gcc 10.1.0 gets this error, before and after applying the patch.

Linking Collada
/usr/bin/ld: ../../../libraries/source/fcollada/lib/libFColladaSR.a(FAXInstanceExport.o): in function `FArchiveXML::WritePhysicsRigidBodyInstance(FCDObject*, _xmlNode*)':
FAXInstanceExport.cpp:(.text+0xbfc): undefined reference to `_xmlNode* FArchiveXML::AddPhysicsParameter<FMVector3, 0>(_xmlNode*, char const*, FCDParameterAnimatableT<FMVector3, 0>&)'
/usr/bin/ld: FAXInstanceExport.cpp:(.text+0xc12): undefined reference to `_xmlNode* FArchiveXML::AddPhysicsParameter<FMVector3, 0>(_xmlNode*, char const*, FCDParameterAnimatableT<FMVector3, 0>&)'
collect2: error: ld returned 1 exit status
make[1]: * [Collada.make:94: ../../../binaries/system/libCollada.so] Error 1
make: * [Makefile:177: Collada] Error 2

He's compiling the latest code from the 0ad GitHub repo, btw.

My friend who is using Manjaro 20, gcc 10.1.0 gets this error, before and after applying the patch.

I have a friend who can't build on Manjaro, an arch derivative, using gcc 10. He's going to apply the patch tomorrow, and I can post results here if still needed. Still needed?

I can't update this revision without creating a new one apparently. So I'll paste it.

In D1617#64738, @Itms wrote:

In D1617#64735, @andy5995 wrote:

I tried. Travis apparently has a 50-minute limit on tests. It terminates the build.

Would it be possible to make Travis pre-generate and cache a development environment where the libraries have been downloaded and built? This doesn't need to be done each time. The rest of the build process will take less than 50 minutes. At first glance this part of the documentation would be the way to go.

but it would be better to figure out how to make macOS work

In D1617#64692, @Imarok wrote:

I think Itms has the best overview about our CI and such things.

Based on @wraitii 's comment in this forum thread, I've removed the osx test from the PR on GitHub.

I tested this patch using Travis..

I applied D1582 and then this patch (@s0600204 said it's dependent on D1582) and I got a complete build on Slackware64-current with gcc 8.2

After reading the comments, I don't really understand what I should do next, if anything. Sounds like you want to fix this with another method, and need to discuss the best approach? I know it's low priority but just thought I'd touch base in case there's anything else I could do with it at the present time.

I tested this patch and added my results to the ticket.