Server policies

[personalized-advertising]

The server can now define a set of policies for freecam mod users, i.e disabling clipping or freecam entirely, much more fine-grained than #547 as you requested.

You can implement this now and then if you later want to make a server-side mod its as simple as doing this from the server:

public static final String FREECAM_POLICY_CHANNEL = "freecam:server_config";

public static void sendFreecamPolicy(Player player, boolean allowFreecam, boolean allowClipping, boolean allowFullbright, boolean allowInteract) {
    String json = """
            {
              "allowFreecam": %s,
              "allowClipping": %s,
              "allowFullbright": %s,
              "allowInteract": %s
            }
            """.formatted(
            allowFreecam,
            allowClipping,
            allowFullbright,
            allowInteract
    );
	
    player.sendPluginMessage(FREECAM_POLICY_CHANNEL, json.getBytes(StandardCharsets.UTF_8));
}

Untested, especially the forge code.

[MattSturgeon]

Thanks for working on this!

As-is, there are a few build failures, open design questions, and a fragmented commit history.

For future reference, grouping commits logically by feature or unit of work (rather than per-file) makes changes much easier to review. Chris Beams' guide to commit messages is a great benchmark for this. On this repository, I also tend to use Conventional Commits, though that isn't a strict requirement.

To save you from having to go through tedious review cycles, I'm going to hold off on reviewing in more detail for now. This and #547 will serve as valuable reference implementations and inspiration when I have dedicated time to sit down and work on this feature.

I'll leave this open for now to keep it on the radar and allow you to iterate, if you choose. Thanks again for laying down the groundwork!

[MattSturgeon]

Can I ask why we're only targeting 1.20.5+? Are we using a packet type that was introduced in that version? Or maybe the FabricServerPolicyNetworking API was added in that version?

[personalized-advertising]

Can I ask why we're only targeting 1.20.5+? Are we using a packet type that was introduced in that version? Or maybe the FabricServerPolicyNetworking API was added in that version?

its because its based on the newer payload format where it has payload type etc.
The mod making new releases for unsupported versions does complicate things a bit, can I ask why there are releases for 1.17 etc? For modded players who want to use old versions can they not just use the older freecam releases from when that version was relevant?

[personalized-advertising]

Thanks for working on this!

As-is, there are a few build failures, open design questions, and a fragmented commit history.

For future reference, grouping commits logically by feature or unit of work (rather than per-file) makes changes much easier to review. Chris Beams' guide to commit messages is a great benchmark for this. On this repository, I also tend to use Conventional Commits, though that isn't a strict requirement.

To save you from having to go through tedious review cycles, I'm going to hold off on reviewing in more detail for now. This and #547 will serve as valuable reference implementations and inspiration when I have dedicated time to sit down and work on this feature.

I'll leave this open for now to keep it on the radar and allow you to iterate, if you choose. Thanks again for laying down the groundwork!

You should look at "Files changed" as a whole, as I implemented the code in an IDE but then copied over the changes file by file using github's built in editor, its a clunky workflow but works for one-off PRs like these.

Also that is my bad, I will remove the forge code.

Also yes this PR can be iterated on by you hopefully it serves as a good starting point, from my side I am just a server developer who wants better compatibility so longer term back and forth for this PR isn't ideal for my as I am already stretched across many projects, hope you understand.

[MrKinau]

Hi @MattSturgeon,
did I understand you correctly: This PR won't be accepted, but you'll work on such feature on your own or will review this at some time in the future? I already asked via mail if a PR which allows server side disabling would be accepted in 2024, but as I did not receive any answer I just thought you are not interested in allowing servers to disable Freecam.
Are you working on a solution, would you review this commit or would you accept another PR (what would be the requirements this PR won't fulfill?).

[MattSturgeon]

Did I understand you correctly: This PR won't be accepted, but you'll work on such feature on your own or will review this at some time in the future?

I completely get the frustration here, especially since this has been sitting in the backlog for a long time. The short answer is yes: the plan is to implement this over the next few Freecam release cycles. I'm hesitant to promise a specific date because my open-source backlog is always shifting, but it is definitely on my radar.

I already asked via mail [...] but I did not receive any answer

I’m really sorry I missed your email. I get a lot of emails and things easily slip through the cracks. For Freecam, the most reliable way to get eyes on a topic is always to use the issue tracker or discussions. If you want to follow the progress on this specific feature, #546 and #105 are the main threads.

Are you working on a solution, would you review this commit or would you accept another PR.

I haven't started active development yet, but I've been thinking through the architecture. I am always open to reviewing PRs, and I'm happy to accept a well-executed contribution that aligns with our roadmap:

1. Step 1 (Basic Support): Implement the client-side handling for the existing AntiFreecam packet. This is a straightforward "disable everything" policy that should cover most bases, and already has a reference implementation.
2. Step 2 (Granular Policies): Build a flexible system where the server sends a JSON payload detailing which features to restrict. Crucially, this needs to act as a temporary override while the player is connected to that server, without altering their actual local config file.
3. Step 3 (Serverside Impl): We could implement serverside integration,
   e.g. when hosting a LAN world, other clients would be sent a copy of the host's freecam policy, though this requires a way to integrate server-policy with freecam's settings config.
   This would also allow a server admin to configure a server policy in a client, then copy the config files to their server.

(what would be the requirements this PR won't fulfill?)

To be clear, the high-level approach in this PR—using a JSON payload over a plugin channel—is actually on the right track and gets the core idea right. There are some details I'd nitpick, but fundamentally it's blocked by unresolved merge conflicts, CI failures, a fragmented git history, and a lack of testing. It also only targets 1.20.5+; a feature like this would ideally support all Minecraft versions Freecam targets.

If someone wants to pick this back up and iron out those mechanical hurdles, I'm more than happy to review it. That said, because getting a PR across the finish line takes real effort, I'd suggest dropping a note in the relevant issues first before diving into code, just to make sure we're aligned on the details.