Surface and Orbit Authority

Idea: The Great Smoothening

Based on the voting thus far, it’s looking like we may end up with “no meteors” passing, which is great because it hopefully means future voxel deformation will end up limited to what we actively do. I have great hopes this will reduce load times for people on planets.

That said… we still have a ton of terrain damage from meteor impacts that isn’t going to go away on it’s own. Derspiny suggested something to me last night, and if people are largely in agreement, I’ll experiment with it a bit. The idea is:

Temporarily crank the voxel GC settings such that it “resets” voxel deformations very close to grids. Now this does need to be carefully tested to ensure it doesn’t end up resetting the hole my base is in. :slight_smile: I’m happy to do a bunch of that testing before we do this on the server, if people like the idea. I’d potentially need permission to take the save from our server, and load it locally to jump around as admin to check that nobody’s base has been covered over by the voxel reset. Once I’ve come up with setting that accomplish useful cleanup without doing any harm (assuming that’s possible) I’ll ask Derspiny to temporarily configure the server that way. (After meteorites are turned off, if the proposal goes that way.)


Edit: Just to clarify: At no point would a save game I had control of locally be uploaded to the server. The sole purpose of me getting a copy of the save game would be to experiment with various voxel GC settings and ensure no bases are negatively affected.

Yes. Full Stop.

and this because my post was too short.

I did some experimenting at lunch, and the results were (eventually) positive:

I still want to experiment a bit more with a bunch of player-drilled deformation with a grid in/around it, mixed with meteor-induced deformation, and see if the cleanup does something remotely sane. If it does, then I think this idea could work, and I’ll write up a proposal for it.

If the automated smoothing doesn’t work, is it possible to just “restart” the server by copying all the grids onto a new save? No idea how the map generation works, but if it’s not random each time, the voxels should be reset while grids remain the same. Again, just throwing ideas out there, no idea if it’s feasible!

Failing that, if it gets too bad, summon the apocalypse and start the server from scratch? This time without any of those pesky meteors. Of course doing it properly with plenty of notice and so on, perhaps even making a little scenario out of it, say people should get a ship to an evacuation point to get it copied over to the new save.

That’s possible yes, however my entire base Is underground, so that would cover it. I’d have to drill it out again, but with the blocks there, it would be impossible to do without damaging/destroying them. So I’m hoping that even a partial cleanup helps things.

I believe it’s possible to reset the voxels en masse, in a few different ways, but I’ve never tried it and would have to experiment. (I believe that the most effective way is to generate a new save, and to copy the voxel files over, removing all other voxel files from the current save.)

It will, as @SurprisingEdge said, bury everything that’s built in a dug-out area, including any players who logged out in tunnels.

I’m going to try to dump what I know/suspect here:

  1. Resetting an entire planet/asteroid means it’ll be like none of the digging there will have happened, so anything built underground (ie. my base) will be completely buried. Not very feasible, since drilling it out is nearly impossible to do without damaging some (many) of the blocks. (Any sort of admin “reset this voxel” or “copy/delete this voxel file” does this.)
  2. The new “voxel cleanup” sort of does what we want, but the granularity isn’t great. It seems like it’s done in “chunks” roughly 2x2x2km, aligned to some sort of grid. So my base could be anywhere inside that chunk, which would prevent any of the voxel deformations in that chunk from being reset. That said, the cleanup could clean up any other chunks on the planet that don’t have a grid in them. (So we may want to clean up some old grids first.) (This “chunk” thing is speculation, but it’s informed speculation based on a bunch of experimenting in single player.)

What I want to do is get a download of our save and try method 2 on it, see how much it shrinks the voxel file by. Maybe it’ll be reasonable. Can’t hurt to try.

We talked about doing bulk cleanup efforts like this by proposal somehow, and at the time I promised to look into how to structure that. I’d like to continue along those lines - and we definitely have some ruins around that could be obliterated, at this point.

I’ve done some work on this. Here’s what I’ve got so far. I’d like some feedback on both the framework - the change to rule 5.3 - and on the actual actions to undertake. Obviously, I need to fill out the actual values for voxel removal. At a guess, those values will be “1 minute,” “100 meters from the nearest grid,” and “0 meters from the nearest player,” but this needs some more testing first.

Thanks to @SurprisingEdge and @David_s for contributing input and reviewing the first drafts of this.


  • Create a framework for voting through actions. My hope is that we never vote through an action without discussing it first, but this gives us a way to propose one-shot obligations or deviations from Charter rules that don’t necessarily make sense in terms of Charter articles.

    I believe the Power framework adequately resolves precedence between instructions (as defined below) and rules: the proposed changes to rule 2.4 clarify that, between instruments of a given power, articles come before other instruments, such as proposals. For example, an instruction to modify game data needs to have a power greater than that of Rule 9.2 (“The Official Server”) in order to override the obligation not to modify game data.

    One ambiguity here that could probably use cleaning up is that an instruction can authorize (and require) an officer to break a standing rule, but can’t alleviate the standing rule entirely. I don’t think this will generally be an issue, but it might require some care in proposal-writing to ensure that officers aren’t left in a damned-either-way situation.

  • Use this framework to drastically shrink the Official Server’s data, so that connecting to it is not such an ordeal. Over the last few weeks we’ve been seeing increasing load times as players connect, and increasing disruption to existing connections caused by new players joining.

    These appear to trace back to bloated voxel data, caused in large part by meteor impacts on the Earth-like planet. The data for that planet is now over 150 MB, whereas it’s under 1 kB on a new save, and @SurprisingEdge has observed that the data transmitted when he connects is approximately that size, leading to a multi-minute ordeal to join the server and a noticable increase in lag for other players.

    By removing abandoned grids and all NPCs, this proposal ensures that as much of the voxel data is “smoothed” - restored to its original state and deleted from the game’s stored/transferred data - as possible. Testing suggests that this should reduce the 150 MB data to around 15 MB - still large, but only a tenth the size. Grids prevent the game from smoothing voxels in a large area around them even with the voxel cleanup settings tuned to be quite aggressive, as the game appears to use a grid-based system to determine what parts of a large voxel to clean up, rather than cleaning up on a point-by-point basis. Every stray grid appears to force a 2km by 2km area of the planet to remain in its eroded and dug-out state.

The Draft

Title: Fine-Grit Sandpaper
Adoption Index: 4.0

Amend rule 2.4 (“Precedence Between Articles”) by changing its title to “Precedence Between Instruments”, and by replacing its text with the following:

In a conflict between instruments, the conflict shall be resolved as follows:

  1. If the instruments in conflict have unequal power, the instrument with the highest power takes precedence;

  2. Otherwise, if both instruments are articles of this Charter, the article appearing earliest in the Charter takes predecence;

  3. Otherwise, if either instrument is an article of this Charter, that instrument takes precedence;

  4. Otherwise, the instrument adopted first takes precedence.

No change to this Charter can occur that would cause an article to directly claim precedence over this rule as a means of determining precedence. This rule takes precedence over any article that would permit such a change to this Charter.

Amend rule 5.3 (“Official Duties”) by appending the following paragraph:

Where permitted by this Charter, an instrument can, as part of its effect, instruct an officer to take action. The officer must perform the action in a timely fashion, once and only once per instruction, in the order the instructions appear in the instrument. The officer should publicly announce that the instructions have been completed after taking action.

Instruct the Space Master to create a backup of the game data.

Instruct the Space Master to remove the following categories of grids from the game:

  1. Grids belonging to players who have not logged in in two or more weeks,
  2. Grids more than 45,000 km from the Earth-like planet,
  3. All grids belonging to NPCs which are further than 100m from a player-owned grid, and
  4. Grids which, at the Space Master’s discretion, appear to be abandoned debris on the surface of any planet.

Instruct the Space Master to smooth the game’s voxels, by the following procedure:

  1. Configure the trash removal settings as follows:

TODO (needs research)

  1. Observe an unoccupied area until the game removes voxel modifications, and

  2. Restore the trash removal settings to their original values.

Instruct the Space Master to restore the backup of the game data if, on inspection of least two asteroid or planetary static grids, any grid appears to have been rendered inaccessible or unusuable due to restored voxel material.

My brain might be a bit fuzzy. Can you give a simple example?

I don’t see anything that jumps out at me that could be a problem with the charter changes.

I recommend a visible change to the MODT that refers to these steps. I will also try to ‘put out flyers’ to our space neighbors who might not visit this forum. Mainly I am thinking they might have an NPC grid they are working on and need to know they should ‘plant a flag’ on it so that it doesn’t get removed.

A lot of thought and effort went into this. Thank you @derspiny.

The situation I had in mind is, for example, an instruction in an adopted proposal to remove an official mod from the server.

  • If the SM removes the mod, they are violating a standing rule in the charter.
  • If the SM doesn’t remove the mod, they are violating the requirement to act.
  • If the SM removes, and then immediately restores, the mod, they’re violating the expectation to act in good faith, because that’s clearly working to the rules rather than to the intent.

Having slept, though, I think my concern last night was overly inflated, and I’m happy to let this go. This has historically been a reasonable group, and I think this is a lot more likely to arise by accident than by deliberate intention to trap an officer in an impossible situation. (An officer so trapped can always resign, too - the choice to limit instructions to officers was a deliberate effort to ensure that people are given ways out of “compulsory” acts.)

I see now. As you say, this would likely be accidental, probably along the lines of we did it and 3 weeks later we realize we are out of compliance with the standing charter. I am ok with the understanding that should we discover we are out of compliance we should fix the charter to amend it to line up with the member intent as soon as is feasible.

For it to be intentional it would have to be very subtle or the result of a hostile takeover, both cases seem very unlikely for now at least.

I’m liking this proposal! Big fan here.

More seriously though:
I’d suggest, for the cleanup settings, doing 1m from players, 1m from grids. Was there a reason to use 100m from grids?

I wanted to pick a margin that would ensure that blocks near the edge of a grid boundary didn’t end up partially buried, regardless of the topology of the grid they’re part of, and 100m felt like a more-than-adequate safety margin.

The settings I tested:

  • Revert voxel materials: yes
  • Revert asteroids: yes
  • Revert with floating objects present: yes
  • Distance from player: 0 m
  • Distance from grid: 100 m
  • Voxel age: 1 min

The server’s current settings, for comparison, are:

  • Revert voxel materials: yes
  • Revert asteroids: yes
  • Revert with floating objects present: no
  • Distance from player: 25,000 m
  • Distance from grid: 10,000 m
  • Voxel age: 1440 min