PP: Better world modification support

[iamgreaser]

I'm thinking that there should be an extension which allows you to, at the very least, place a coloured block without having to force a different player's block colour. This would form a nice base for Issue #24 (Build Mode Extension).

• It should, at the bare minimum, allow one to place a single block of a single colour at a single location WITHOUT having to set a player's block colour first, and also allow one to clear a block.
• Being able to set a cuboidal region to a given block colour, or clearing said cuboidal region, would also come in handy.
• For something like a rollback, being able to set a rectangular region and/or an arbitrary cluster of raw VXL pillars at once would speed things up tremendously.
• None of the above proposed packets will make any sounds, except maybe as an option for a single block packet.
• None of the above proposed packets will make any blocks fall, except maybe as an option for a single block packet.

I believe all of the above combined together would form a good baseline, giving a good feature set without making a mess of the implementation.

Backwards compatibility has its difficulties here. Here are the options.

1. Fall back to the usual vanilla methods whenever someone is using a client which doesn't support this extension. This will result in a generally awful experience and a lot of finger pointing.
2. Kick clients which don't support the extension, but tell them to rejoin before kicking them. This is the cleanest solution.
3. Make clients which don't support the extension reload the map. If you can implement this as some sort of "virtual kick and rejoin" then this miiight work.
4. If running a build server, autokick clients which do not support the extension, and tell them to use a recent enough OpenSpades / BetterSpades / whatever. Or alternatively, keep telling them to do that, and opt for Option 1.

[NotAFile]

Regarding the fallback options, I started a ExtensionFallbackPolicy mechanism in pique which would allow protoexts to specify if a fallback is possible and allow scripts and admins to specify if they require full compatability or not. Unless full compatability was required (i.e. policy is kick), only the subset of the features that a fallback is available for would be enabled.

I think the ability to send raw vxl spans to override a region (especially without physics update) is very needed, it's been discussed before. Not as sure about the single block placing, as scripts like platform.py seem to have that worked out?

[iamgreaser]

Regarding the fallback options, I started a ExtensionFallbackPolicy mechanism in pique which would allow protoexts to specify if a fallback is possible and allow scripts and admins to specify if they require full compatibility or not. Unless full compatibility was required (i.e. policy is kick), only the subset of the features that a fallback is available for would be enabled.

Sounds good. In theory you should be able to somehow make this all work on a vanilla client, but in practice it's going to make it a pain in the arse for those who support the extension and suddenly everyone has to fall back because the vanilla client doesn't support the extension.

Not as sure about the single block placing, as scripts like platform.py seem to have that worked out?

The latter likely uses a spare player ID, and the use of spare player IDs is kinda dodgy considering that you tend to start mangling structures that you aren't supposed to because the bounds checking in the vanilla client is disgustingly absent.

hi greaser

Hi. I found out very recently that you made a client and I'm impressed.

[NotAFile]

suddenly everyone has to fall back because the vanilla client doesn't support the extension.

To be clear, this would be a per-connection thing. So the fallback would only affect voxlap players.