question

This is how a event driven simulation works. No event, no action. What you assumes is a action of a possible event. The operator becomes a buffer. But he is just a supporter. It is an action based on an uncertain forecast.

You can place a queue directly previous to the processor. When the operator loads the item, you stop the queue. The operator travels to queue, but he can't unload the item, because he is blocked by the an inactive queue. You resume this queue when the item of the processor exits.

OnLoad Trigger Operator: execute stopobject command, if processor is still busy

/** call stop on unload station  and set state to busy*/
treenode curTS = gettasksequence(current,0); 
      // active tasksequence
Object unloadstation = gettaskinvolved(curTS,5,2);
Object processor = unloadstation.outObjects[1];
      // relative reference, directly model().find("Processor1")
if(processor.subnodes.length) stopobject(unloadstation,STATE_BUSY);
      // subnodes length is the content of the processor
      // State busy doesn't exists at a queue
      // I can identify this stop at this queue now exactly.

OnExit Trigger Processor: resume queue if on state busy

if(current.inObjects[1].stats.state().value=STATE_BUSY)
    resumeobject(current.inObjects[1]);

3D-model: 3d-in-advance-transport-item.fsm

ProcessFlow is easier without any additional objects. You let the operator load the item and travel to the processor. A wait for event activity holds the operator in place, until the item on the processor exits.