⚠️ Attention
This issue description was generated with the assistance of a large language model (LLM) and may contain inaccuracies or incomplete assumptions.
The content should be treated as a starting point for discussion rather than a finalized design.
Background / Motivation
All mod features are currently host-only.
This was an intentional design choice.
This mod is a cheat mod, and therefore explicit host consent should be required.
Restricting all functionality to the host avoids the complexity of RPC design, permission checks, and authority management,
and helps keep the design intent and overall direction of the mod clear, while also making it easier to maintain.
Another important reason for this approach is the preference to rely on vanilla RPC patterns provided by the base game, Lethal Company, without introducing additional custom networking layers.
However, this also means that clients cannot use any mod features by themselves, even in cases where client-side usage would be safe and useful.
If client-accessible features can be enabled without introducing significant complexity or fragile logic, it may be worth revisiting this design—even if that means carefully introducing minimal custom RPCs.
For example, cruiser jumping can currently be practiced by the host, but its behavior may differ slightly between host and guest players due to networking differences.
Currently, guest-side practice is only possible by coordinating closely with the host, or by running and repeatedly switching multiple game instances, both of which are inconvenient.
Allowing guest-side practice would make independent practice possible.
As part of this direction, host-side mod installation can be treated as an explicit form of consent for enabling cheat-related functionality and allowing client-triggered interactions.
Goals
- Explore how mod features can be safely used by clients
- Keep the implementation simple and robust
- Avoid complex permission models or fragile RPC chains
- Prevent abusive or disruptive client-triggered behavior (including host-side configuration to permit client usage or not)
- Require explicit host consent via mod installation
Design Constraints
- This mod assumes that the host always has the mod installed
→ Host installation represents explicit consent
- Simplicity is a priority
→ The goal is not to keep features host-only, but to keep the overall design simple.
Client feature support should avoid unnecessary complexity, fragile state synchronization,
or overly elaborate permission systems.
If complexity increases, the design itself should be reconsidered.
- Due to the authority and RPC model of NGO / Lethal Company,
and the desire to rely on vanilla RPC patterns as much as possible,
mod features have so far been implemented as host-only
Proposed Direction
Allowing client usage will likely require introducing some level of custom RPCs, as vanilla RPC usage alone is not sufficient for client-triggered interactions.
Rather than fully abandoning the existing approach, the intent is to introduce minimal and explicit client-to-host communication, scoped only to what is strictly necessary.
The key question is not whether custom RPCs are avoided entirely, but whether they can be introduced in a way that keeps the overall model simple, explicit, and maintainable.
There may also be a secondary benefit to introducing minimal custom RPCs.
Reducing reliance on vanilla RPC behavior could make the mod easier to adapt if the internal RPC implementation of Lethal Company changes across versions.
High-level Approach
Minimal Client → Host Interaction
- Clients send explicit requests for mod actions
- The host receives and handles these requests using a small, well-defined RPC surface
- Execution happens on the host, consistent with the existing authority model
This keeps the flow explicit and avoids implicit or stateful client-side behavior.
Validation Considerations
Introducing client-triggered actions raises the question of how much validation is necessary on the host side.
This needs to be carefully scoped:
- What assumptions can reasonably be made about client behavior?
- What minimal validation is needed to prevent obvious abuse or invalid state?
- Where is the boundary between necessary sanity checks and over-engineering?
The goal is to keep validation minimal and explicit, rather than building a full permission or anti-cheat system.
Acceptance Criteria
- Client feature usage does not significantly increase implementation complexity
- Custom RPC usage remains minimal and well-scoped
- Host authority and consent remain explicit and enforced
- The design remains understandable and maintainable
- Client support is achieved by simplifying the model, not by adding layers of indirection
Notes
This issue is intentionally cautious.
Client access is desirable only if it can be achieved with a simple, explicit, and host-authoritative design.
Introducing custom RPCs is acceptable if it serves this goal, but complexity itself is not.
Background / Motivation
All mod features are currently host-only.
This was an intentional design choice.
This mod is a cheat mod, and therefore explicit host consent should be required.
Restricting all functionality to the host avoids the complexity of RPC design, permission checks, and authority management,
and helps keep the design intent and overall direction of the mod clear, while also making it easier to maintain.
Another important reason for this approach is the preference to rely on vanilla RPC patterns provided by the base game, Lethal Company, without introducing additional custom networking layers.
However, this also means that clients cannot use any mod features by themselves, even in cases where client-side usage would be safe and useful.
If client-accessible features can be enabled without introducing significant complexity or fragile logic, it may be worth revisiting this design—even if that means carefully introducing minimal custom RPCs.
For example, cruiser jumping can currently be practiced by the host, but its behavior may differ slightly between host and guest players due to networking differences.
Currently, guest-side practice is only possible by coordinating closely with the host, or by running and repeatedly switching multiple game instances, both of which are inconvenient.
Allowing guest-side practice would make independent practice possible.
As part of this direction, host-side mod installation can be treated as an explicit form of consent for enabling cheat-related functionality and allowing client-triggered interactions.
Goals
Design Constraints
→ Host installation represents explicit consent
→ The goal is not to keep features host-only, but to keep the overall design simple.
Client feature support should avoid unnecessary complexity, fragile state synchronization,
or overly elaborate permission systems.
If complexity increases, the design itself should be reconsidered.
and the desire to rely on vanilla RPC patterns as much as possible,
mod features have so far been implemented as host-only
Proposed Direction
Allowing client usage will likely require introducing some level of custom RPCs, as vanilla RPC usage alone is not sufficient for client-triggered interactions.
Rather than fully abandoning the existing approach, the intent is to introduce minimal and explicit client-to-host communication, scoped only to what is strictly necessary.
The key question is not whether custom RPCs are avoided entirely, but whether they can be introduced in a way that keeps the overall model simple, explicit, and maintainable.
There may also be a secondary benefit to introducing minimal custom RPCs.
Reducing reliance on vanilla RPC behavior could make the mod easier to adapt if the internal RPC implementation of Lethal Company changes across versions.
High-level Approach
Minimal Client → Host Interaction
This keeps the flow explicit and avoids implicit or stateful client-side behavior.
Validation Considerations
Introducing client-triggered actions raises the question of how much validation is necessary on the host side.
This needs to be carefully scoped:
The goal is to keep validation minimal and explicit, rather than building a full permission or anti-cheat system.
Acceptance Criteria
Notes
This issue is intentionally cautious.
Client access is desirable only if it can be achieved with a simple, explicit, and host-authoritative design.
Introducing custom RPCs is acceptable if it serves this goal, but complexity itself is not.