sending "global" triggers

[KG_is_back]

Hello, I want to ask if there is a way, to send trigger wireless upwards in hierarchy. Let's say I have a module(s) buried very deep and want them to send trigger to totally unrelated places throughout the schematic (sort of a "global" trigger which updates all modules sensitive to it). Wireless only works other way around - sending triggers deeper into schematic. View connectors are more promising (you can cause redraw from basically anywhere), but using them to send triggers doesn't seem right...

[tulamide]

I was just looking for exactly the same, but didn't find a solution. However, if it doesn't need to be a backwards trigger explicitly, then there's alternatives. Exo and a few others were building a callback system (http://www.dsprobotics.com/support/viewtopic.php?f=2&t=3264&p=17931&hilit=callback#p17931) and chakl made something quite similar, thanks, Nubeat, for the link (http://www.dsprobotics.com/support/viewtopic.php?f=3&t=1646&p=7442#p7442)

Both work with the fact that you can access any RubyEdit from anywere in the schematic, given you have a valid adress. So, instead of sending a trigger backwards they call a method from the top layer instance.

[KG_is_back]

I'm aware of this, I'm using similar method to transfer global data. Basically in the topmost module I have a ruby module, that sends hash of global values via wireless link. If one module changes any value in that hash, the value is available in all modules. However, sometimes I need to trigger other modules, to respond to that change. Having each module to check for all relevant changes is nonsense (since one of the hashes is a "map" - an X*Y array of hashes)

[Nubeat7]

i don't know the exact situation, but in general i always try to create the schematics in a way to avoid very deep nesting, i normally have all the main modules like: GUI controls, audio FX, Globals, Modulators on one level where they interact together via wireless connections, like this the way you need to transport values up usually is not too bad or often can be avoided

a good way to do it is a wireless uplifter to avoid too much confusing outputs..

[KG_is_back]

I will try to redo the schematic in more sensible way. However, I doubt it will be possible to avoid these kind of problems completely. I'm attempting to make a strategy game in Flowstone. The GUI has two main parts (the bar and the map) and the data displayed there needs to interact closely.
Basically the entire schematic has to be able to run in two modes: "editor" for map editing and "play" for gameplay. Both "map" and "bar" modules (both displayed on the main GUI) need to have two different GUIs for each mode, with some elements present in both modes (for example the entire drawing part and scrolling part of "map" module is shared by both modes).
At first, this layout made sense (for the editor part it was fine) but then I needed to display unit-stats on the bar, when unit is selected and there was nothing in the schematic to tell the "bar" module that something has happened in "map" module.

[tulamide]

I will try to redo the schematic in more sensible way. However, I doubt it will be possible to avoid these kind of problems completely. I'm attempting to make a strategy game in Flowstone. The GUI has two main parts (the bar and the map) and the data displayed there needs to interact closely.
Basically the entire schematic has to be able to run in two modes: "editor" for map editing and "play" for gameplay. Both "map" and "bar" modules (both displayed on the main GUI) need to have two different GUIs for each mode, with some elements present in both modes (for example the entire drawing part and scrolling part of "map" module is shared by both modes).
At first, this layout made sense (for the editor part it was fine) but then I needed to display unit-stats on the bar, when unit is selected and there was nothing in the schematic to tell the "bar" module that something has happened in "map" module.

Ah, now I see. That differs from what I am looking for. (I'm looking for a way to update Ruby inputs that hold Ruby objects, after they were copypasted. Green after dup doesn't help there)

It is always advisable to seperate GUI- and content-data. So that you have one module "data" and the two modules "map" and "bar". This way it doesn't matter where (visually) a change was made, the center of all content is "data". As long as both modules are connected to "data" in the right form, the will be aware of every change. Also, you don't need to actually send data back and forth, instead just access it.

[KG_is_back]

It is always advisable to seperate GUI- and content-data. So that you have one module "data" and the two modules "map" and "bar". This way it doesn't matter where (visually) a change was made, the center of all content is "data". As long as both modules are connected to "data" in the right form, the will be aware of every change. Also, you don't need to actually send data back and forth, instead just access it.

Yes, that's basically what's happening. I have a main module in the parent that sends a hash of data everywhere. The hash contains references to objects, instead of their copies, so whenever any module does something with an object in that hash, the change is available anywhere. Transferring values works OK, but there is nothing to trigger events in other modules, to respond instantaneously to value changes in the global data.

Now that I think of it, I may send "self"(a reference to the rubyEdit) in that hash and then from any module I can force output method on that main ruby module.... why didn't it occurred to me sooner!

[tulamide]

Now that I think of it, I may send "self"(a reference to the rubyEdit) in that hash and then from any module I can force output method on that main ruby module.... why didn't it occurred to me sooner!

That's one way to do it. But isn't it easier to output after having processed the input? Your main module should have inputs and thus control the flow of information. You can then send explicitly to the module that needs the new data.

Basically something like this:

Code: Select all

def event i, v
if i == 'from map'
#process changes done by map module
output 'to_bar', whatever it needs
elsif i == 'from_bar'
#process changes done by bar module
output 'to_map', whatever it needs
end

Or even just send triggers. If a from_map trigger arrives, send a trigger to to_bar, and vice-versa.

[Perfect Human Interface]

Not to be "unhelpful" but have you considered using a game development platform? They seem to handle game-related issues far more gracefully.

I remember trying out using Ruby global variables as per that thread tulamide linked, and though I had some issues I think they're avoidable if you're exporting to exe or VST. In theory of course a value change could be converted to a trigger.