You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 12, 2019. It is now read-only.
If we have AutoConfigure, why not AutoStart or TakeRun?
This could be done but I'd like to brainstorm how best to expand the automation functionality. Right now we have a special BoolT FM parameter for EXIT and AUTOCONFIGURE, so instead of making more and more special parameters, we could devise an all-purpose automation parameter. I am thinking the best solution is to replace the current automation parameters with a MapT that specifies a map of {state: command} to carry out automatically, i.e. an automatic start could be encoded as:
My first thoughts are that that format would make it a lot easier to define new automated actions in the future; e.g. one would not have to give a special name to a sequence of actions and implement it specifically; instead one would either:
a) put the exact JSON for a series of steps into the GUI code, and handle it there, or
b) abstract it out of the GUI a bit; instead, have the GUI send e.g. a StringT AUTOSTART over to the server side, and then the FM server-side code can populate the correct series of actions into the JSON parameter. That way the GUI code could be less in charge of defining the sequences for a particular routine. [This solution would probably mean creating two new parameters, the MapT that specifices the actions (populated on the server side), plus a StringT that the GUI populates for the GUI to send over to the server-side--it would read the StringT and then populate the MapT of actions.]
The text was updated successfully, but these errors were encountered:
Taken from #330. Notes from that issue:
This could be done but I'd like to brainstorm how best to expand the automation functionality. Right now we have a special BoolT FM parameter for EXIT and AUTOCONFIGURE, so instead of making more and more special parameters, we could devise an all-purpose automation parameter. I am thinking the best solution is to replace the current automation parameters with a MapT that specifies a map of {state: command} to carry out automatically, i.e. an automatic start could be encoded as:
My first thoughts are that that format would make it a lot easier to define new automated actions in the future; e.g. one would not have to give a special name to a sequence of actions and implement it specifically; instead one would either:
a) put the exact JSON for a series of steps into the GUI code, and handle it there, or
b) abstract it out of the GUI a bit; instead, have the GUI send e.g. a StringT
AUTOSTART
over to the server side, and then the FM server-side code can populate the correct series of actions into the JSON parameter. That way the GUI code could be less in charge of defining the sequences for a particular routine. [This solution would probably mean creating two new parameters, the MapT that specifices the actions (populated on the server side), plus a StringT that the GUI populates for the GUI to send over to the server-side--it would read the StringT and then populate the MapT of actions.]The text was updated successfully, but these errors were encountered: