simList's .inputObjects phaseThe continuation shared by simInit() and restartSimInit(): schedule each module's
.inputObjects as a real event, drain that phase through the same single-event step as
the spades loop (.stepEvent()), then schedule init events, fill dot-params, and
finish initialization (.finishSimInit()). Having one implementation means the normal
and resumed paths cannot drift.
.runInputObjectsPhase(
sim,
recoverMode,
allInputObjNames,
thisSpadesCallRandomStr,
modulesLoaded
)A finished simList.
A simList whose sim@.xData[["._simInitContext"]] has been populated.
Recovery parameters passed
through to .stepEvent(). simInit passes its values; restartSimInit passes
recoverMode = 0 (a resume does not re-arm recovery).
The loaded-modules list with the core modules already appended; the user modules are appended here.
It is re-entrant: modules whose .inputObjects already completed (recorded in
completed(sim)) are not re-scheduled, and init events that already exist are not
duplicated. So restartSimInit() simply rewinds, removes the completed-marker of the
module(s) to re-run, and calls this -- mirroring how restartSpades() hands back to
spades().
The drain loop is kept inline here (rather than in a further nested helper) so that the
queue updates from each processed event are retained in this frame. On an error mid-
drain, recovery state lives in shared environments -- the objects and
sim@.xData[["._rmo"]] in sim@.xData, and sim@completed -- so it is preserved for
restartSimInit() even though this function's local sim is discarded.