LivoxProto1: invoke enablePcloudDataReq
Sadly we don't get to immediately see the results of our work because we have to do a unified dispatcher for the incoming UDP messages on the command channel.
This commit is contained in:
@@ -33,6 +33,27 @@ void Director::intrinEventInd(void)
|
||||
|
||||
void Director::postrinEventInd(void)
|
||||
{
|
||||
/** EXPLANATION:
|
||||
* When a postrin event occurs, a goal is auto-generated, but this goal is
|
||||
* a bit different from the goals that are auto-generated for negtrins.
|
||||
*
|
||||
* A negtrin's goal is to either: get to 0; reduce the negtrin below its
|
||||
* intolerable threshold; or reduce it somewhat even if not below the
|
||||
* tolerable threshold. This is very easy to represent as a cologex.
|
||||
*
|
||||
* A postrin's goal is to: persist the postrin indefinitely; and increase
|
||||
* its intensity if possible; and to store it away as something worth
|
||||
* re-triggering if some external distractor/frustrator interrupts the
|
||||
* persistent sampling of the postrin.
|
||||
*
|
||||
* I can think of how to encode the negtrin goal as a cologex, but I can't
|
||||
* think of how to encode the postrin goal as a cologex.
|
||||
*
|
||||
* With respect to the "store away for future re-triggering" aspect of the
|
||||
* postrin goal we can encode this by merely refusing to remove any postrin
|
||||
* goal from the goal prioQ. I suppose negtrins differ in that we do remove
|
||||
* them from the goal prioQ when they're resolved.
|
||||
*/
|
||||
std::cout << __func__ << ": Handling postrin event." << std::endl;
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user