Openra: Unite mod DLLs?

[penev92]

This was suggested by @chrisforbes and is something that has crossed my mind a few times before.

Currently there is little code in each of the mod DLLs, and a ton of code in Common. The difference for Common would be negligible, but this would make the "Can this mod/map use trait X that is from mod Y?" issues a lot better.

[23:23:58]< chrisf> things that turn out to be useful will move into common code and slowly get more general
[23:24:17] < Phrohdoh> certainly, but where do we draw the line?
[23:24:40] < chrisf> im not sold on there _being_ a line for things like traits.
[23:24:50] < Phrohdoh> Then we should just have a mods.dll
[23:24:52] < chrisf> if you have some weird ui junk, sure, keep that in your own dll

I know we've talked about splitting Common to "graphics stuff" vs "logic", or "sprite stuff" vs "voxel stuff" or whatever. Maybe we can dump all the stuff in Common first. Then have Activities.dll, Traits.dll, Traits.Render.dll, etc. or whatever we name them.

At this point I am not sure how much point there is to have per-mod DLLs (custom mods of course will add their own logic in their own DLLs) for the official mods, considering how little code they actually contain.

Opening this for discussion. I particularly want to hear what @reaperrr and @GraionDilach think about this, as people with their own mods, because I think this will affect them. Of course we need opinions from the other people interested/involved/capable on commenting on the project's architecture.

(I'm not going to label this issue for now because it's a Question that I hope will quickly move to an Idea about a Refactor.)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Phrohdoh]

I've suggested this quite a few times but iirc @pchote has his reasons for us not doing this, so if someone digs those up from the logs they'd be a good addition to this ticket.

[GraionDilach]

I am a scavenger and adopter by nature. I personally see no difference in either case.

The sole thing I can think of that if all traits be moved to Common, rejecting anyone's own traits even though out of scope - like RA2 traits or written-for-mod-only stuff - is less justified than the current "shared traits in Common, mod-specific logic for the mod" direction which at least imply that traits without a usecase in the shipped mods are less welcome.

[Mailaender]

Hmm, at first I didn't like the idea at all, but after some thought this may be a good solution for easier re-using. We should keep the namespaces for context of the very specialized traits which have less value for reuse and shouldn't be generalized. The argument for having separate DLLs is to avoid loading everything, but as the Mods.Common library is the largest anyway, it probably won't matter performance wise. Splitting everything in Activities.dll, Traits.dll etc. makes no sense either, because then you again need to reference everything and just refactored for nothing.

[penev92]

It does make a lot of sense because having 3 more using statements is much better than getting lost in the 1500 files you have in this project, spread among 10 folders.

[reaperrr]

I'm with @penev92 on this one, a single monolithic dll is much harder to navigate and keep organised. we already have too many subfolders in the Traits folder for my taste, for example.

And one important argument in favor of lots of smaller dlls: it would be much easier for third-party mods to exchange/remove parts of Common that they don't like or don't need.

[reaperrr]

In #12554 we've pretty much settled on:

• D2k dll will stay separate as an example for 3rd-party mods
• the other official individual mod dlls have been merged into a single OpenRA.Mods.Cnc.dll
• Mods.Common will stay separate from that
• Some relatively general purpose stuff may get moved back to Common later (I'm thinking of at least Infiltration and paratroop-related stuff, for example), while at least some WW-specific file formats will move "downstream" into Mods.Cnc

As the merge of the CnC dlls has already happened, I think this can be considered either "solved" or "wontfix", depending on how flexible one is on the details of this issue, but I think either way it can be closed.