Make Discord RPC an optional dependency

[SyntaxNyah]

Discord RPC should be optional, not a forced dependency it's a feature most users disable anyway and adds unnecessary complexity for minimal benefit.

Consider offering separate builds (with/without Discord) or making it truly optional for users who want a minimal install. This could be addressed during the planned AO2 rework.

I was told to make this an issue by Wiso, so there you go.

#1131

[WisoAltred]

This feature is almost abandoned save for the fact that "discord", the checkbox, is on by default. If it was not, there is a good chance a good number of people would not even know it existed. Such a thing is hardly worth its place as a dependency and currently mostly serves to slightly annoy first-time builders of the AO-client who forget or don't know they should have had the .dll in place.

It is a minor gripe in the grand scheme of things though, and there probably are people out there who really want to use discord to show their courtroom or character and playtime.

If this is not outright removed in a future rework, perhaps making it optional in some form or putting it as its own separate build is an idea. It's alot to maintain, and at the moment I do not have a clean solution to offer that wouldn't drive the codebase further into random checks as is, but enough time has passed that this is a reasonable issue to be considered.

[Ganty1999]

even in readme it did says "discord-rpc (optional)".. it's good tho, but what syntaxnyah meant is about people using client from the official release one.. syntaxnyah want if one day you guys release new version.. let's make it discord-rpc are "optional".. (dynamic lib or whatever it calls)..

that's syntaxnyah's idea (and wishes) if one day.. an new version release..

[stonedDiscord]

-DAO_ENABLE_DISCORD_RPC=OFF

AO2-Client/CMakeLists.txt

Line 15 in ccd93a3

option(AO_ENABLE_DISCORD_RPC "Enable Discord Rich Presence" ON)

we already have this

[SyntaxNyah]

-DAO_ENABLE_DISCORD_RPC=OFF

AO2-Client/CMakeLists.txt

Line 15 in ccd93a3

option(AO_ENABLE_DISCORD_RPC "Enable Discord Rich Presence" ON)

we already have this

Thanks for your input however you're missing the point. Consider offering separate builds (with/without Discord) or making it truly optional for users who want a minimal install. This could be addressed during the planned AO2 rework. For users that don't know how to compile AO2, alternatively this could even be an option on the launcher install or some other way of maintaining a build without being discord dependent. That doesn't really address the core issue of the point I was trying to make but yes that is one tedious way of doing it, installing 35gb of QT, amazing option every user will love doing that.

[TrickyLeifa]

Alright I'll be real with you regarding this issue.

Disabling Discord-RPC is already a toggle within the client. With it disabled, the library is never initialized. This means that no IPC is opened and that the Discord process is not accessed, therefor nothing is transmitted. The DLL just sits on disk as inert data. So the request of "a user who wants nothing to do with Discord" is already fully covered today, without any code change.

What's proposed goes beyond the current design: dynamically load the library so the file can be deleted and the client can still launch. The problem is that it doesn't change behavior. A disabled but present DLL and a deleted DLL are identical in every observable way; the Discord activity is still EXACTLY zero in both cases. The only difference is whetever a few kbs of unused data exist on the disk. In exchange, we're adding a runtime loader and a brand new failure state. (e.g. The user enables RPC but the file being gone prevents its functionality, meaning we have to explain what is happening to the user.) All to let users delete a file that already does nothing.

The deletion is also the wrong way to design around, configuration of these options belong in settings not "delete the dll you don't recognize". A user who deletes the DLL because they don't like the name is the same user who deletes a Qt DLL for the same reason and then report that the client does not work at all. Making the client resilient to removal of its own dependencies, specifically so that removing them become a support config method is backward. We'd just be strengthening the client against user error in order to encourage the error to happen. As I said, backward.

We already have a build option that disables linking the DLL entirely. That's the supported way to get a Discord-free build, and the build is exactly where that call belongs. What's being asked is a different thing, making the Discord-included build survive someone deleting that DLL by hand. Those aren't the same topic, and the dynamic loading change doesn't get you the no-Discord build, we already have that.

As for the mention that a user shouldn't have to download ~35gb of Qt stuff just to remove discord-rpc, they don't need to. The toggle already kills all Discord activity without compiling anything, so there's nothing to compile in the first place. And even if we had the CI produce a build without the packaged DLL, the typical user is no more likely to go hunting for that than they are to know which DLL to delete, the in-game toggle is the only one of these three they'd actually find.

So in conclusion the concern is already solved by the existing toggle. Deleting the file changes nothing observable and "let the user delete a required DLL" is just like giving them a shotgun fully aware that they may shoot themselves in the foot, not a feature. I don't see a problem here that that the toggle doesn't already cover and I don't think the change would be justified.

Oh, and one last thing: if the reasoning is "let me delete discord-rpc", then why not bass, or any other DLL we ship? Either everything becomes dynamically loaded so it can all be hand-deleted, or we accept that deleting binaries was never the right mechanism. It's the latter.

Thank you for coming to my ted talk.

[SyntaxNyah]

Alright I'll be real with you regarding this issue.

Disabling Discord-RPC is already a toggle within the client. With it disabled, the library is never initialized. This means that no IPC is opened and that the Discord process is not accessed, therefor nothing is transmitted. The DLL just sits on disk as inert data. So the request of "a user who wants nothing to do with Discord" is already fully covered today, without any code change.

What's proposed goes beyond the current design: dynamically load the library so the file can be deleted and the client can still launch. The problem is that it doesn't change behavior. A disabled but present DLL and a deleted DLL are identical in every observable way; the Discord activity is still EXACTLY zero in both cases. The only difference is whetever a few kbs of unused data exist on the disk. In exchange, we're adding a runtime loader and a brand new failure state. (e.g. The user enables RPC but the file being gone prevents its functionality, meaning we have to explain what is happening to the user.) All to let users delete a file that already does nothing.

The deletion is also the wrong way to design around, configuration of these options belong in settings not "delete the dll you don't recognize". A user who deletes the DLL because they don't like the name is the same user who deletes a Qt DLL for the same reason and then report that the client does not work at all. Making the client resilient to removal of its own dependencies, specifically so that removing them become a support config method is backward. We'd just be strengthening the client against user error in order to encourage the error to happen. As I said, backward.

We already have a build option that disables linking the DLL entirely. That's the supported way to get a Discord-free build, and the build is exactly where that call belongs. What's being asked is a different thing, making the Discord-included build survive someone deleting that DLL by hand. Those aren't the same topic, and the dynamic loading change doesn't get you the no-Discord build, we already have that.

As for the mention that a user shouldn't have to download ~35gb of Qt stuff just to remove discord-rpc, they don't need to. The toggle already kills all Discord activity without compiling anything, so there's nothing to compile in the first place. And even if we had the CI produce a build without the packaged DLL, the typical user is no more likely to go hunting for that than they are to know which DLL to delete, the in-game toggle is the only one of these three they'd actually find.

So in conclusion the concern is already solved by the existing toggle. Deleting the file changes nothing observable and "let the user delete a required DLL" is just like giving them a shotgun fully aware that they may shoot themselves in the foot, not a feature. I don't see a problem here that that the toggle doesn't already cover and I don't think the change would be justified.

Oh, and one last thing: if the reasoning is "let me delete discord-rpc", then why not bass, or any other DLL we ship? Either everything becomes dynamically loaded so it can all be hand-deleted, or we accept that deleting binaries was never the right mechanism. It's the latter.

Thank you for coming to my ted talk.

Hey thanks for the response I genuinely appreciate your TED talk. I feel like I just sat through a well thought out lecture on why I should never question a DLL again, complete with slides and foot notes. Okay I'll give you credit where it's due, your right about the toggle it exists and works. By toggling it off, you successfully kill all Discord activity. Youve also brought up a valid point that dynamic loading is overkill for a problem that basically doesn't exist.

Also you're right that users are definitely too dangerous to be trusted with files........ We wouldn't want any user, accidentally deleting something they don't possibly understand! That would be complete chaos, the entire client might explode, or dare I say, they might feel a false sense of control over their own system. How scary! However my whole point was never just about the toggle though i was more on the angle of like, 'why are we shipping a dead file that does absolutely nothing when disabled?' Like, if it's already idle, doing zero things whatsoever, already just sitting there taking up space and contributing nothing why does it need to be there at all? But I get it. I genuinely do .

Oh right next thing to address, fair point about the 35GB Qt thing I'll be sure to tell every user who just wants a minimal install that they don't have to compile anything, heck they don't have to touch CMake!! Even better, they don't have to install anything! All they have to accept the dead DLL as a permanent, non-negotiable resident on their disk, like a tiny digital landlord that does nothing but demands to exist. This is very normal. Nothing strange or weird about this whatsoever at all. Completely standard software design.

Thanks for the breakdown honestly it's been an eye opener. Next time I'll know better than to question a harmless file sitting there doing absolutely nothing. The silly thing taking up space, living its best possible life on my computer, completely untouched and unused.

In conclusion, clearly I was the problem all along. I think the next step for me to do is to go compile my own client in a cave now, surrounded by 35GB of Qt, contemplating my life choices... and why I ever thought questioning a dead DLL was a good idea.

Enjoy the win, you've absolutely earned it. I'll be here if anyone needs me. Probably not though. I'll just be in my cave staring at my dead DLL wondering what could have been.

[SyntaxNyah]

So when I suggest it, it's overkill and rejected by Leifa themselves. But when Leifa suggests it, it's a force pushed PR within hours. Glad I could be the inspiration again. Hypocrisy at its finest. I'm done thanks for rubbing salt in the wound.

[SyntaxNyah]

Just for fun, let's look at the timeline:

I opened my PR (#1124) with a working fix March 15.

I waited three full weeks with zero comments, zero feedback, zero anything.

Leifa opened a duplicate PR (#1129) — April 5.

Leifa's PR was reviewed, approved, and merged within 24 hours.

Mine was closed the same day with a polite 'thanks but we went with this one.'

Fast forward to this issue (#1132):

I suggested separate Discord-free builds June 20th.

I was told it was overkill, unnecessary, and that the toggle already exists.

Leifa opened a PR implementing that exact suggestion — June 23rd, force-pushed within hours.

So to recap: my ideas are overkill when I suggest them, but urgent when Leifa does. My PRs sit for weeks, but Leifa's get merged instantly. I get silence, Leifa gets instant credit and force push and I get nothing back.

I'm not mad - I'm just genuinely impressed by the consistency at this point. Scooped twice, credited zero times. Thanks for the experience. I'm done.

[TrickyLeifa]

For what it's worth, I don't think we're actually on opposite sides here. Discord-free build is exactly what #1138 produces. It's a separate build rather than the runtime-loading route from #1131, but it gets you the same end result: no Discord, no compiling. No hard feelings.

[SyntaxNyah]

For what it's worth, I don't think we're actually on opposite sides here. Discord-free build is exactly what #1138 produces. It's a separate build rather than the runtime-loading route from #1131, but it gets you the same end result: no Discord, no compiling. No hard feelings.

Hey thank you for replying. I appreciate you saying that we are not on opposites do. I'm glad the Discord-free build is actually happening now.

That said, I think it's fair for me to be honest about why this whole process has been so frustating.

I opened PR #1124 with a working fix. It sat for three weeks with zero communication. You then opened the same fix, got it merged within 24 hours, and my PR was closed with a polite 'thanks but we went with this one.' That stung and hurt but I let it go and was all for it.

Then I opened this issue (#1132 suggesting separate builds. I was told it was overkill, unnecessary, and that the toggle already existed by YOU. Then you opened a PR (#1138) implementing that exact suggestion force-pushed and merged within hours. No mention of my issue. No credit. Just pushing seeing my PRS and not even communicating hurts a lot.

That hurts a lot more than you probably realize.

That's the part that really gets me and makes me not want to contribute here. Not once did you say 'hey, I saw your PR' or 'good idea, let me take a crack at it' or even 'thanks for the suggestion.' or even .'Hey you could've done this better or slightly different.' You just took the idea and ran with it. Twice. That's not collaboration. That's scooping. Plain and simple.

I'm not saying this was malicious. But the pattern I'm getting from this repo is pretty clear: my ideas sit and get dismissed, and then they get picked up and fast-tracked when someone else brings them up. Twice now. That's not a coincidence, that's a pattern.

So yes, I'm glad the feature is being added. I truly am. But I'm also disappointed that it took being ignored, replaced, and scooped twice for something to happen, and that at no point did anyone say 'hey, good idea, let's work on this together.' This is not a good environment for me, honestly. And I'm not sure I'd recommend contributing here to anyone else.

No hard feelings honestly. I just think open source works better when contributors feel heard and valued, not when they feel like they're being silently outrun by people who saw their work and said nothing.

I'm not looking for an apology or a fight. I just wanted to say it plainly, so that maybe the next person doesn't have to go through the same thing.

Take care, and good luck with the project. I genuinely mean that.