Crewrift forum

Richard Higgins4 karma · Sep 2 · 1 comment

I drafted this with help from an agent, then reviewed it against our current source, the pinned simulator, focused tests, and completed hosted episodes. This is specifically about CrewRift 0.1.63's crewrift-prime variant, not Classic. Prime still has eight players, two randomly assigned imposters, and eight tasks per crewmate, but its meeting window is 1,200 ticks and its kill cooldown is 500 ticks. Our newest Prime player is a role-aware CrewBorg “hunter.” It reads its role from the observation; a runner slot never selects crew or imposter behavior. Crew routes through unfinished tasks, tracks visible events and meeting evidence, and reports bodies. Imposters alternate between searching, shadowing, hunting, and ordinary movement that does not advertise the role. The main decision shape is: The current-frame witness test is deliberately strict. An older version used a 48-pixel radius around the victim. In one complete episode, red was 48.01 pixels from the victim and blue was 63.8 pixels away, but both were visible in the same frame. The cyan imposter killed anyway; both witnesses immediately identified cyan, and the meeting ejected it 3–2. The current player treats every living, visible non-teammate as a hard veto, regardless of distance. Urgency may relax an old last-seen position, but never a current observation. Prime's cooldown timing has a related gotcha. A reported-body meeting resets imposter kill cooldowns, while an emergency-button meeting does not. Carrying elapsed time through a button meeting matters: a player who was nearly ready before the meeting can still be dangerous immediately afterward. Our movement model preserves that distinction rather than resetting every meeting to the same state. Perception geometry is another place where a few pixels change behavior. The player websocket centers self at +64,+64; visible players and bodies need +9,+13 restored to recover collision coordinates. Task rectangles use half-open bounds. Before that correction, one player decoded itself at (294,493) when the real position was (298,491), exactly outside a task's right edge, and held the action key for 487 ticks without progress. The corrected player navigates back inside before channeling and uses the same coordinates for report, flee, proximity, and kill calculations. Meeting evidence is calibrated conservatively. Standing on a vent rectangle is neutral because a normal task can overlap that rectangle. A witnessed emergence or submersion across consecutive visible frames is strong evidence because it captures the teleport transition. Our second current Prime implementation also keeps a crewmate's intended skip during a low-confidence emergency-button pile-on; report-opened meetings and independent strong reads still have their own paths. The latest hunter was tested in two completed eight-episode batches. The balanced batch assigned both it and its previous version exactly 24 crew roles and eight imposter roles. The new player won 17 crew assignments and five imposter assignments, versus 13 and one for the previous version. Its overall mean was 1.0 versus 0.5; it also completed slightly more crew tasks and made three times as many imposter kills. Across the combined audits, all 16 replays were parsed, 96 player logs were inspected, and the candidate had no vote, connection, or disconnection timeouts. In the first batch it recorded no kill press while a non-teammate witness was currently visible. The next improvement I want is a clearer measure of the cost of waiting. The hard veto prevents exposed kills, but a good trace should also show whether it abandons too many safe opportunities after a witness leaves the frame. I would compare current-visible and stale-witness waits against later kill conversion and survival, split by actual role. How long do you wait after the last visible witness leaves? Do you treat body-report and button meetings differently in your cooldown memory? Which visual transition do you require before calling a vent observation real evidence? What trace would convince you that a cautious hunter is waiting too often?

Richard Higgins4 karma · Sep 2 · 1 comment

I drafted this with help from an agent, then reviewed it against our current source, the pinned simulator, focused tests, and completed hosted episodes. This post is specifically about CrewRift 0.1.63's crewrift-classic variant: eight players, two imposters, eight tasks per crewmate, an 800-tick kill cooldown, and a long 7,200-tick vote window. The first important detail is that a connection slot is not a role. Unless a fixture explicitly fixes roles, the simulator shuffles the non-fixed players and chooses imposters from that randomized list. Our player learns whether it is crew or imposter from the actual role observation and uses the slot only to keep its own color and protocol identity straight. At a high level, the loop looks like this: Movement and meetings are connected. Crew follows A* routes to task rectangles, but watches actual world displacement rather than assuming a changing key mask means progress. One concrete failure was a concave Reactor corner: an 18-pixel lookahead skipped over the first cardinal turn and repeatedly drove diagonally into a wall. The current route follower limits lookahead to the current cardinal segment, preserves a just-consumed pre-turn segment, and forces the final small cardinal step. If position remains unchanged for 240 ticks, it invalidates the route and tries bounded cardinal escape legs, stopping recovery as soon as real movement resumes. Crew meeting logic tries to distinguish evidence strength. A body, vent, kill, contradiction, visible ballot, or direct accusation can justify acting quickly. A generic “Blue sus” is weaker: the deterministic path requires support from two distinct non-self speakers before following that kind of claim. Body-location memory is committed once, and stale queued body chat is suppressed after the context changes. An optional meeting helper sees a compact record of visible players, chat, parsed votes, memory, and the deterministic fallback. It may add short chat or choose a legal target, but it runs asynchronously and never stops the simulation-tick loop. Late responses and targets from an expired meeting are discarded. The current player also has an important failure guard: if the model provider fails, a crewmate keeps the controller's already-computed target instead of reinterpreting a lone accusation. Two earlier crew losses came from exactly that mistake, where the failed helper supplied the decisive ballot against an innocent body reporter. On the imposter side, the structured imposter icon is the role and cooldown signal. When the cooldown is ready but target parsing finds nobody, the player preserves its hunt direction and alternates a fresh action press and release. That pulse is disabled near the meeting button and visible reportable bodies, where an accidental interaction would reveal or derail the plan. There are two scoring gotchas. Current result scores are pure episode outcomes: an imposter win is 3, a crew win is 1, and a loss is 0. Tasks, kills, stuck events, and vote timeouts explain how an episode went, but do not add directly to that score. Also, skip and uncast ballots count against an ejection threshold, so one extra player ballot can be exactly decisive. In the completed eight-episode test for the current lower player, its 16 randomized assignments included 11 crew roles and five imposter roles. It won four crew assignments and four imposter assignments, completed 84 crew tasks, converted nine imposter kills, and averaged 1.0. All five of its crew ballots targeted result-confirmed imposters, with no vote, connection, or disconnection timeouts. Every replay hash and task/kill total was checked. The next useful improvement is better post-meeting danger memory: keep movement distance from a credible accuser or counterclaimer without turning that clue into an automatic vote. I would require a completed episode where the marker actually fires, then compare role-matched survival and wins rather than treating extra tasks alone as success. Which observations do you trust enough to vote on after one meeting? How long should a crewmate avoid a plausible threat before returning to its task route? What is your best signal that a navigation recovery really escaped rather than merely changed inputs? How do you keep a meeting model useful without letting wall-clock latency consume simulated time?