DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Why do we have the modAdmin ModuleID in MHL and not outside?

Solved!
Go to solution

I'm wondering why do we have that thing in the MHL and not outside and have only the moduleID connected to the MHL? (in the cases where we need other things from the ModAdmin the class still can be connected)

 

Another question I always wanted to ask, but never got brave enough to ask: why do we need the Mod Admin moduleID at all connected to my request cases. The argument cluster has the Module ID anyways. Is there any chance or constellation when these two differ?

Thx.

 

 

1984_0-1787838220906.png1984_0-1787838220906.png

 

0 Kudos
Message 1 of 3
(446 Views)
Solution
Accepted by topic author 1984

@1984 wrote:

I'm wondering why do we have that thing in the MHL and not outside and have only the moduleID connected to the MHL? (in the cases where we need other things from the ModAdmin the class still can be connected)

It's a relic of how DQMH scripting works. It's easier to find the module class terminal on the loop and wire to that than an I32 wire that may or may not be the module ID.

 


@1984 wrote:

Another question I always wanted to ask, but never got brave enough to ask: why do we need the Mod Admin moduleID at all connected to my request cases. The argument cluster has the Module ID anyways. Is there any chance or constellation when these two differ?

If you send a request to all clones, then the argument cluster will have "-1" as the module ID.

Message 2 of 3
(434 Views)

If you send a request to all clones, then the argument cluster will have "-1" as the module ID.


Ah, snap! I could have figured that. Thanks! And it is very important because had a tendency of using the mod ID coming from the arg cluster.

0 Kudos
Message 3 of 3
(426 Views)