Mergability

[SollyBunny]

My client tries to stay with infclass-client because I like the features but right now infclass client is to put it bluntly a pain to merge.

Would PRs be accepted to make that less the case.

The first step is reenabling all the checks and fixing all the issues that come up.

The server is also disabled, I know that server would just be the DDNet server but I think as to not remove a feature of the DDNet client, should be reenabled.

There are also lots of attempts to make the branding less hardcoded, would be nice if all of these were upstreamed as I am not very savy with the build systems and I'm really scared of breaking things

[Kaffeine]

Hello. As you may guess, I'm not ready to put work into this.

right now infclass client is to put it bluntly a pain to merge.
Would PRs be accepted to make that less the case.

It depends.

The server is also disabled, I know that server would just be the DDNet server but I think as to not remove a feature of the DDNet client, should be reenabled.

The server would be DDNet but IMO for Infclass bundle we should have Infclass server (if any). There is server build for windows (produced by CI at https://github.com/infclass/teeworlds-infclassR) and I had a plan to bundle it to Infclass client releases. I don't want to build and include DDNet server because it would waste CI time and increase the package size.
Right now I have to wait about 6 minutes for a build, and with server enabled I'd have to wait almost twice longer.

The first step is reenabling all the checks and fixing all the issues that come up.

There are the following checks:

1. clang-sanitizer
2. clang-tidy
3. codeql-analysis
4. rust
5. style

I've decided to disable them all because they've regularly caused merge conflicts (in the .yml files), they are (or were) branded (have/had hardcoded ddnet where now infclass) and they require the server.

(Back in time) I'd keep the style CI but the used clang-format is (too old and) not available in Ubuntu-22.04, and I didn't want to waste time installing legacy stuff. See ddnet#7033. You can work on this issue if you want to improve the situation.

However, considering pros and cons, it sounds fair enough to enable style CI. Ok, I'll do it eventually.

It would be cool to enable other C++ checks but it won't work as-is without the server, and it would cause conflicts if I'd patch it out.

There are also lots of attempts to make the branding less hardcoded, would be nice if all of these were upstreamed as I am not very savy with the build systems

As far as I understand, DDNet is not interested in such changes. They'd cause quite a lot of work with no direct profit for them.

heinrich5991 on Sep 20, 2024:
I'd probably like to decline all modding-related PRs that do not improve something for DDNet itself (unrelated to the moddability)

It is quite disappointing for me, and I'm not ready to spend time on DDNet.

I'm really scared of breaking things

That's very reasonable. IMO this is quite blocked by DDNet releasing process — they manually build the client on a developer's PC, and I've accidentally broke it every time I touched something. Since 7777 I'd rather RQ.

[SollyBunny]

I think removing hardcoded instances of "DDNet" would be accepted, atleast in the build system where localization isn't an issue.

Since ddnet#7777 (comment) I'd rather RQ.

Fair enough