ZDoom

Oh whoops. I was catching up on old unread messages, just parsed the last couple comments, and thought it was still under debate :oops: My bad.

8-)

It [i]has[/i] been implemented, as the [Added] tag in the thread title implies.

I'll throw another use case on the stack since I rolled my own trying to solve a similar issue.

I have a "modular" mod pack, which I've designed so players can load the entire mod as one unified whole, or easily separate out just the parts they want. But of course this causes problems if one of these "sub-mods" depends on another one that isn't loaded.

For example, one of my modules gives the player a flashlight inventory item. Another module gives monsters some enhanced AI mechanics, including the ability to use the same flashlight item as the player. But if the AI mod is loaded and the flashlight isn't, errors occur.

So I wrote a system in the "core" submod (common routines used by all the mods) that allows the AI mod to send "intents" such as "toggle flashlight" to a global "bulletin board", and the flashlight to look for these intents and toggle accordingly.

Details spoilered since my [i]implementation[/i] is irrelevant to the one discussed in this thread, but just for context.
[spoiler]The implementation: [url=https://github.com/caligari87/Ugly-as-Sin/blob/master/core/module/core_intents.zsc]Ugly as Sin [c]core_intents.zsc[/c][/url]

AI monster example of sending intent:
[code]// More likely to activate in darker areas
if (random[aillm](0,192) > lightlevel) { UaS.SendIntent("LLM_Toggle", "On", owner); }
else { UaS.SendIntent("LLM_Toggle", "Off", owner); }[/code]

Flashlight receiving intents:
[code]void ProcessIntents() {
UaS_Intent oi;

oi = UaS.GetIntent("LLM_Toggle", owner);
if (oi) {
if (oi.Payload ~== "On") { activated = true; }
else if (oi.Payload ~== "Off") { activated = false; }
else { ToggleSwitch(); }
oi.Clear();
}

oi = UaS.GetIntent("LLM_ModeSwitch", owner);
if (oi) {
int m = oi.Payload.ToInt(10);
switch(m) {
case 0: modeLaser = 0; modeLight = 1; break;
case 1: modeLaser = 1; modeLight = 0; break;
case 2: modeLaser = 1; modeLight = 1; break;
case 3: modeLaser = 0; modeLight = 3; break;
}
oi.Clear();
}
}[/code][/spoiler]

If this was implemented into GZDoom I could save some code and probably be more efficient. I think one main thing I like about mine is that it includes several fields like separating the intent name and payload string, sender/receiver pointers, timeouts, etc. Not sure how generically useful those might be or if they can be achieved with MC's system.

8-)

static ui bool, int getMaxFromService(string className)
{
	ServiceIterator i = ServiceIterator.Find("MaxHealthService");

	Service s;
	if (s = i.Next())
	{
		String maxHealth = s.UiGet(className);
		if (maxHealth == "none")
		{
			return false, 0;
		}
		else
		{
			return true, maxHealth.ToInt();
		}
	}

	return false, 0;
}

class StubMaxHealthService : Service
{
	override String UiGet(String className)
	{
		if (className ~== "DoomImp")
		{
			return "1000";
		}
		else
		{
			return "none";
		}
	}
}

That guess is actually 100% accurate. Here's an example.

m8f's TargetSpy modification has a service that searches for MaxHealth named services that allows overriding the display of a monster's maximum health. As his mod is doing the searching anything with MaxHealth, this is how its set up.

[code]static ui bool, int getMaxFromService(string className)
{
ServiceIterator i = ServiceIterator.Find("MaxHealthService");

Service s;
if (s = i.Next())
{
String maxHealth = s.UiGet(className);
if (maxHealth == "none")
{
return false, 0;
}
else
{
return true, maxHealth.ToInt();
}
}

return false, 0;
}
[/code]

Any mods that wish to make use of this just need to do something like this (note: there is a Get for Play and UIGet for UI scopes):
[code]class StubMaxHealthService : Service
{
override String UiGet(String className)
{
if (className ~== "DoomImp")
{
return "1000";
}
else
{
return "none";
}
}
}[/code]

And that's it.

I think the goal is to modularize addons. If there is a standard for addon-to-addon communication it makes it possible to establish a generic framework for them, or even any number of them, while making some parts of addons optional and reducing overall addon cross-dependency while increasing cross compatibility. That's just my guess, though.

I'm going to take your word for it. I still can't wrap my head around a potential use case.

Alright, I gave this a thorough testing, and it seems to work as anticipated, which is very useful for cross mod messaging indeed. I hope Graf will consider merging this.

I'll implement this into QZDoom soon. Sorry for not responding sooner. Just been busy with RL but things have finally settled down.

I've changed the implementation so the service iterator accepts partial name matches too.
So, modA1 defines "HealthService_A1", modA2 defines "HealthService_A2", modB searches for "HealthService" and finds both.

I had to remove the convenience method ServiceIterator.ServiceExists(). Now the only way to know if there are no Services found is to count how many times Next() returns not NULL.

I updated the PR, and here is the standalone preview:
[attachment=0]service-new.zip[/attachment]
There are four directories in this archive, each is meant to be loaded separately, with service directory first.

Thank you for understanding. I look forward to what you might come up with next. This is a very powerful feature that could greatly ease plenty of stuff.

Major Cooke, you are right. I have to think about a way to service provider mods not to conflict. I'll use your idea with setting actual service name if I don't come up with something more convenient.

Eeeee.....looks like we have problems understanding each other.
Just wait for m8f, he should explain it better than me.

Class D4MaxHealthGetter : MaxHealthGetter

yes, but that's exactly the problem. If you want to make it inherit from type MaxHealthGetter defined in TargetSpy so it's taken into account, that means any mod that implements:

[code]Class D4MaxHealthGetter : MaxHealthGetter[/code]

...become reliant upon that mod being present at all times. Sure, could just inherit from Service directly, but specifying a name to search it by means it's basically going to skip over it, unless it's used for, say, 'private' service classes.That works fine for things such as libraries, sure, if that's what its intended use case is.

Inheritance from Service class I meant. It would be included in gzdoom.pack, so it would be there in any case.

Doing it by inheritance means that it relies upon the other mod being there, and that won't work at all.