-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ModuleConnector: allow module instances communicate with each other #141
Comments
cc @Ondina |
Have you seen this comment too? |
Yeah I saw it, but though that's ok as a temporary solution, this is something that needs to be fixed. |
Of course. |
Wow, you're totally losing me :) How does that exactly help? You'd still need to do this: [Inject (name='A-and-B')]
public var eventDispatcher:IEventDispatcher;
eventDispatcher.dispatchEvent(ModularConnectorEvent.A_TO_B_MESSAGE); Right? We're still talking about a module instance sending events to other instances of the same module, right? |
Yeah, I deleted the bs. My intention was to have a dispatcher for the inter-instances communication that doesn’t relay any events and kind of a local interceptor that would decide what to do with the received event, maybe made clear in the mappings or a guard ...weird, I know. As I understand (still studying the code), the infinite loop is caused by having the same dispatcher as a receiver and as a relayer, listening to and dispatching the same event. The moment it receives the event, it relays it again. Anyway, I’ll continue studying the ModuleConnector & Co and keep my mouth shut ;) |
No, no, that's how solutions are found. 99% BS and 1% good ideas. At least |
I remember worrying about circular relays.. and even possibly coming up with solution.. and then totally forgetting. The fix probably needs to live in the |
I made another attempt to break the infinite loop. BS or not, but it works. I couldn't create a gist for some reasons, so here is the code: [1] localDispatcher dispatches Here is the loop breaker:
I looked at the EventRelay and I think it's not the right place to make changes, since all it does is adding and removing listeners and it shouldn't have to know about events being dispatched. I also thought about using event's useCapture and phases or event.stopPropagation() inside of EventRelay , but I couldn't work it out, maybe because it doesn't make sense at all? Sorry for the ramblings, but infinite loops are dizzying... I'm sure you'll come up with something better, so I'm really very curious about your solution to that ouroboric situation :) @darscan could you, at least, give me a hint about the solution you had in mind |
Interesting solution! I honestly can't remember where my thinking was at regarding this stuff. I'll have another dabble this w/e, and give more thought to your solution as well. |
@darscan alright, there is no rush Another thing I've tried was to have a callback function for each dispatcher, where they'd let the other dispatcher dispatch the event only if it wasn't already dispatched, depending on a counter. I could make it work only for instances of the same module. Somehow the counting was messed up for other modules and I gave up on this approach. Btw, I changed the code a bit:
and added the type (EventRelay.addType) to the _types only if the type is not in _types. [EDIT] |
Progress report https://github.com/Ondina/robotlegs-bender-modular-air/wiki/ModuleConnectionConfigurator---take-2 It's just a draft. I add listeners to the parentDispatcher:
and to the localDispatcher:
The handlers:
|
https://gist.github.com/Ondina/6138055 |
If you try to have several instance of the same module communicate with each other through the module connector, you run into an infinite loop:
see http://knowledge.robotlegs.org/discussions/robotlegs-2/3327-go-modular-for-multiple-games
The text was updated successfully, but these errors were encountered: