Service interface for cross-mod communication

Like feature suggestions, but you've actually written code to make it happen. More likely to make it into the game than some random request in feature suggestions.

Moderator: GZDoom Developers

Forum rules
Please see Code submission guidelines

GZDoom Status:
Image

Legacy Status:
Image Image

QZDoom Status:
Image

Service interface for cross-mod communication

Postby m8f » Wed May 13, 2020 6:05 am

PR

This add interface for cross-mod communication. This is a means to make optional mod dependencies.

Service class provides a single virtual method, String get(String request), which can be overridden in Service implementation. Then, clients will be able to find that service via ServiceIterator.

Usage example is provided in the PR.
User avatar
m8f
dreamer
 
 
 
Joined: 29 Dec 2017
Location: Siberia (UTC+7)
Discord: m8f#0629
Github ID: mmaulwurff
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit

Re: Service interface for cross-mod communication

Postby m8f » Thu May 28, 2020 11:27 pm

There is a discussion on this pull request on the GitHub, I'm putting it here too, so maybe it may help me get more insight into the problem. Until I understand the issue, I cannot adapt the code to fit the developers' requirements.

edward-san wrote:Interesting. How does this approach cope with multiplayer mode, where clients may have different loaded mods for various purposes, like graphics and etc.?

m8f wrote:This is an alternative to cross-mod communication via EventHandler.SendNetworkEvent. If the data that is passed between mods affects the game, mod authors have to use EventHandler.SendNetworkEvent.

Graf Zahl wrote:So in other words: This completely bypasses the network barrier?
You wouldn't expect modders to cluelessly use this and make their mods incompatible with multiplayer and demo recording?

Sorry, but we set it up this way so that modders won't accidentally create such mods - of course nobody will ever stop them from deliberately screwing things up - but I don't think it's a good idea to provide ready-made solutions to do such things.

...
Graf Zahl wrote:If it can cross the network barrier it will completely circumvent all the protections we added to the engine to ensure that modders won't accidentally create mods that break demos and multiplayer, so yes, it should be restricted to one side of it.

...
m8f wrote:Honestly, I don't see how this introduces a new problem.

S1. Players involved in a netgame can load different sets of mods. Suppose that Player1 has a mod that Player2 doesn't have. Then if this mod changes the game, players will desync. I just checked this, it works like this. There is no protection from this situation besides "out of sync with..." message.

S2. If players have the same service-client combination, then service and client will behave the same, both service-client pairs working on their own side of network barrier. They don't "bypass the network barrier".

S3. If players have different service-client combinations:
S3.1. servers cannot cause different changes in the game because they are data-scoped. Even if they could, see S3.2.
S3.2. clients may behave differently depending on the supplied data from server (or lack of such information). This is an issue, of course, but it's the same issue that is described in S1, which already happens without Services.

If I'm wrong, please correct me. I feel that I don't understand something here. If you have time, please explain. I also will be glad if I'm pointed to a source where I can read on the subject.
User avatar
m8f
dreamer
 
 
 
Joined: 29 Dec 2017
Location: Siberia (UTC+7)
Discord: m8f#0629
Github ID: mmaulwurff
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit

Re: Service interface for cross-mod communication

Postby Rachael » Fri May 29, 2020 3:24 am

As long as there's no way to share data between Play and UI outside of SendNetworkEvent then there is no issue. I think Graf's biggest concern is precisely that - if there's a way for the Play scope to access UI data, then this is no bueno.

I haven't looked at it but I can't confirm whether this is the case or not.

The idea is - the UI scope is supposed to be volatile - things can change in it that absolutely cannot be depended on and also do not get synchronized across all network nodes (including demo playback).

The play scope is supposed to be the complete opposite - the data is supposed to be reliable, dependable, and should only be able to change with precise algorithmic calculations that occur every tic and depend on data that you can rely on being sync'd (i.e. network events, player input states).

Requiring players to all have the same mod (unless it's UI-only mods) is a given.

If this is the case with this submission and it follows my explanation here, then it would be good to just let him know.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Service interface for cross-mod communication

Postby m8f » Sun May 31, 2020 2:03 am

Thanks, Rachael!

Now I get it, indeed, there was an issue with scoping - it was in Data scope, which is accessible from both Play and UI. I added proper scoping now.
User avatar
m8f
dreamer
 
 
 
Joined: 29 Dec 2017
Location: Siberia (UTC+7)
Discord: m8f#0629
Github ID: mmaulwurff
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit

Re: Service interface for cross-mod communication

Postby Major Cooke » Mon Aug 03, 2020 1:40 pm

Merged into QZDoom for testing.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007


Return to Code Submissions

Who is online

Users browsing this forum: No registered users and 0 guests