8 lines
1.6 KiB
Markdown
8 lines
1.6 KiB
Markdown
# Crew behavior
|
|
|
|
`getMissionParticipants` uses `bs_groupsystem:getPlayerPartyId(citizenid)` and `sendToPartyMembers` to snapshot online crew members at mission acceptance. It resolves each member's current Qbox player via `GetPlayerByCitizenId`, then records `{citizenid, source}`. Solo missions snapshot the initiator. Each mission keeps a citizenid→mission map and typically one global mission instance. `participantIsValid` currently requires the snapshotted source to still represent the same citizenid; reconnecting to a new source does not automatically rejoin a live mission.
|
|
|
|
Crew objective UI uses `updatePartyTasks` and sometimes `sendPartyNotification`. Existing task labels and status formats vary: some missions use `current/pending/done`, others use booleans. Preserve payloads during extraction; inspect the installed group-system behavior before standardizing. Easy Rider shares bike count and delivery count with the original crew, with one bike per participant up to five. Crowbar 5's package carrier owns the ambush and cash payout; other snapshotted eligible players receive progression. Mid-mission joiners do not receive mission rewards.
|
|
|
|
The target crew service should own snapshot, membership validation, source resolution, objective fan-out, tracker updates and notifications. Mission modules should declare collective versus owner/carrier objectives and reward policy. Use citizenid for eligibility and source only for current delivery. Define disconnect/abort policy explicitly before changing it; the current implementation does not offer general reconnect reconstruction.
|