CitiesSkylinesMultiplayer / CSM

Source code for the Cities: Skylines Multiplayer mod (CSM)

Home Page:https://citiesskylinesmultiplayer.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mod support

kaenganxt opened this issue · comments

I see two general approaches for implementing mod support. Either we provide an API to send and receive commands and the mod authors can implement the logic in their mods. Or we implement the mod support into the CSM mod and inject the logic code into the other mods like we work with the base game. I would personally prefer the first approach, because the mod authors know their implementation needs better than us. For important mods which don't decide to implement these features, we could still do it on our side.

So the steps to do this would be:

  • Implement command API into CSM
  • Write good documentation and tutorials on how to work with our mod
  • Ask mod authors to support multiplayer or open pull requests in open source repos (if possible)
  • If mod author refuses to do this, implement support into the CSM mod

The implementation would consist of the same things that we do with the base game:

  • Look for user interaction (either with directly modifying the interaction code or injecting into the handlers)
  • Check if the interaction actually changed anything
  • Send over a command with the needed attributes
  • Perform the same actions (e.g. simulate the user interaction) on the other side
commented

I think the second option would be a pretty smart move right now as there are quite some people in the discord who are interested in joining the development but have troubles getting into the code.

I think the first approach really is the best, it allows CSM's code to stay rather clean. Because (taking TM:PE as an example) it means that TM:PE related code is inside the TM:PE repository. Otherwise CSM will have a huge folder structure with loads of miscellaneous code.

The benefits with the first approach is that it's more stable. The second approach means that we rely on internals.
If CSM instead has a stable (essentially non-changing) API that the mod authors implement it means that they can change much of the internals and at the same time change the handlers and commands around them.

As an example, say something was done internally to TM:PE, like a refactor. A developer would have to open a pull request into TM:PE that would change it, while at the same time making a pull request into CSM to follow this change.

It means that the slightest commit and change over at TM:PE can break our compatibility.

I think the second option would be a pretty smart move right now as there are quite some people in the discord who are interested in joining the development but have troubles getting into the code.

I wouldn't say that this is a valid argument, those developers could just open a pull request into their selected mods or make an exception and put it here (only for closed source mods I guess the rule would be, or if a pull request was fully rejected.)

commented

exception and put it here (only for closed source mods I guess the rule would be, or if a pull request was fully rejected

I also think that a proper API would be better for mod support but right now a good documentation will really accelerate this project not just with mod support but mostly with the base game and DLCs. I mean if we would implement TM:PE without the documentation would make most people happy and if the API is finished we could move the TM:PE sync code over to the API.

Perhaps you are (or I am lol) confused here.

Scope of this issue

Support for syncing mods, how should it be done and where.

Proposition one: First approach

CSM would build an API (to clarify an API is just any interface, CSM would build an official way to intigrate with it), this would be documented well for mod authors to read and use, enabling this syncing. Code would be placed in the respective mod's repository.

Proposition two: Second approach

CSM takes over the full responsibility of implementing this support. CSM injects code to call its handlers and call different functions from itself into the mod. The same way that CSM currently injects code into the game itself. This would depend a lot on internals.

What you're suggesting?

You seem to suggest making good internal documentation for confused developers who need guidance in the mod's workflow (out of the scope of this issue). And what you're proposing is a third option: stress out an implementation of the second approach. Then we go back and go through with the first approach. This to just quickly satisfy the want for that support. Personally I don't think that's good, the second approach isn't necessarily a faster approach.

Hello,

What's the status of this feature? :)

We would really appreciate the opportunity to play CS with mods; especially the TM:PE mod.
So if you can use the help of two Java-Developers, feel free to ask.

Greetings!

Hello,

I'm looking into this and potentially start some kind of development on this and here is my take...
What I was thinking was... if we can find the mods that are enabled in game, we can through reflection maybe, check which ones implement our API and then from CSM just call an init method on the other mods code which would serve as a way to register handlers and so on.

Does anyone have any idea on how we could get the mods enabled? 🤔

Thanks

Hey,

Just providing some updates on this.
We have started the development of this features.
As of right now we have found a way for the CSM mod to be aware of the other mods.
The command serialiser method as been moved to a util to allow the move of both command and command handler to the API package.
The command receiver has been changed to instead of getting the classes from this mod to get any class from any mod that extends command handler, thus any mod that implements the same structure as we do (commands and handlers) using our API will be automatically called.
For sending we have built a proxy class to enable implementing mods to call our send All method.
It’s still a very raw API but at least as of right now it’s working.

next steps are to expose the IgnoreHelper to the implementing mods and we’ll do an implementation test on the TMPE mod as a proof of concept.
Also we still need to figure out if we want to check or even if we bother about not active mods. Because they are still loaded into the game we are still checking those and linking them with our code, which doesn’t bring any real issue since nothing will or should trigger it BUT it a few extra calls that we could otherwise avoid.. performance..

Anyone willing to help is welcome and any feedback on either the code or what was written here is welcome.

Thanks,
João Lourenço

Hey everyone,

I've come up with some documentation already around this: https://github.com/CitiesSkylinesMultiplayer/CSM/wiki/Mod-support
If you can, just give it a look and provide some feedback.

Thanks

Implemented by #270
Support for specific mods should be requested at the respective authors.
TM:PE support is tracked in #289