Antigriefing issues

[midspace]

Griefing issues that have been raised with me.

1. Griefers are going into the console of a Station, and switching it to Ship. Understandably, a station that has been purpose built into an asteroid will lose it's place. Additionally, any blocks that intersect the asteroid surface will be destroyed as a result.
2. Griefers are repainting ships and stations. Usually pink.

Would like to look at all of these issues, and see if we can come up with a simple effective solution to either prevent, or recover from these problems.

[midspace]

Hackers report: http://forum.keenswh.com/threads/01-076-011-ds-exploit-hacking.7357363/

Gives me the idea that we could implement a form of copy/paste protection. New grids can be detected by the server. If the new grid is over X blocks, delete the grid and warn the player. A second attempt could kick the player.

edit: this may not work as well as I first thought. Consider that ships and stations are spawned in game initially. This can be detected as within the first minute of game start. I think VRage.Library.Utils.MyGameTimer may tell us how long a game has been running for to give us a 'grace' period. However, this does not account for Cargo or Encounter (Exploration) ships, as they are spawned in randomly. Cargo ships will have an AutoPilot object entity, but Exploration ships do not. Unless we do some sort of grid matching against the currently listed prefabs.

[midspace]

About the repainting ships, I was hoping we could get API access to the ShipBlueprints. That way, we could use the ship blueprint to repaint an existing ship based on the same blueprint.

[EnochMiningCorporation]

Could any of these be possible? I believe they would help a lot to tackle griefers:

• Logging of login/disconnect per player (at least to chat, then admin can review chat history). Log should include datetime.
• Logging of 'player damaged/destroyed another player/faction's block(s)', with a cooldown to prevent log spam where someone destroys a shitton of blocks over a short period. Again, logging to chat would mean it's reviewable by admin in chat history.
• Logging of player entering a defined area, say the server has 'neatural' station at center which keeps getting griefed, having a log of all players that entered the area can help identify players involved.

Failing inclusion into this awesome script of yours, inclusion in SE itself might be the next step.

[Spcemarine]

I had the following concept in mind: As an admin you could define certain areas where blocks cannot be destroyed (the areas are defined by center, size and form: cubic or spherical). The users can fly into these areas if they want their ships to be protected. Later, when we have access to the hand tools, we can allow the owner of the grid to modify his ship and also we can prevent ppl from adding their own blocks to the grid to become BigOwner. Also we could allow the users to configure their ships so that they can allow their faction members to modify the ship or allow certain players to do that or even everyone. That's in short what I have in mind for antigriefing. In addition to define antigriefing areas we should allow it to invert the settings so that by default nowhere blocks can be damaged except for admin created areas.

[jpcsupplies]

Coming at Spcemarines idea from the role play angle - I have made use of your commands to prevent changes or weld/grinds to a base located at the centre of the map. Aim being this will eventually become the spawn point (and disable spawn ships).

In a role play context, this could be considered the "main space station" as such ships in the hanger there could be considered "secure space" - and preventing other users messing with other peoples ships would work quite well.. if you can find a way to make that work.

Short term you could have something like ships in that region automatically get the flags "cannot be damaged or grinded" downside here is they need to leave this space to work on their ship - and the code to protect ships strikes me as rather heavy (removes/re-adds entire ship)

But it is also possible to have a ship that "cant be damaged" but "Can be grinded" so perhaps then what is needed here is an ownership check, plus check it is in a specific area in space, and if so, allow the ship to be altered by its owner - or even give the owner access to the command to lock or unlock grinding but only on their own ship when it is in secure space.

This has other advantages too, noobs will most likely congregate at this station, and be rubbish at flying, so while they play space ship ping pong working out how to fly their ships at least they dont break anyones stuff !

Or in short, That is an excellent idea.. however you need to decide if you want to introduce the extra overhead this will create into the admin mod, or split it off into its own anti-grief mod.

[jpcsupplies]

Also in regard to repainting.. structures in the protected area would periodically check and set the protect flags.. given it basically removes and adds them again.. at the adding stage it could revert back to its original state (and color) but that means saving out the ship; which introduces more overhead .. the best option here is simply make sure color is included in the vanilla implementation of protected flags.. so you cant damage/grind OR repaint protected items.

[Spcemarine]

Concerning the ownership check: I'd love to do this and I'd have already done it if was already possible. The issue is that I get the grinder as the damaging entity but in the API there is no interface for it. Therefore I cannot do that at the moment but when we get it whitelisted I'll implement some useful kind of protection checks and settings like share with faction. ;) In regard to painting I doubt that it is a "damage event" what means that we have no chance to prevent it properly. And like you said to check that grid every time is a little too much.

[jpcsupplies]

If someone does a push request with a change to the main space engineers community github source; that includes paint color in the indestructable flag checks that is probably the only effective way to deal with that - assuming keen accepts that request. It seems trivial and logical enough it has a good chance of being accepted :) --- actually coding it might not be as trivial tho :(

[Spcemarine]

Well, it would be quite easy to make such changes but recently Keen did not merge a single PR no matter if it was reasonable or not. So I don't have high hopes for that. :/

[zrisher]

Yeah they've put a freeze on it. Hopefully will pick back up soon. I've been coding with the expectation that what we have now is what we'll have to work with for a while, though.

[midspace]

I'm pushing the "Convert to ship" button issue to Keen to fix by restricting it to the ship owner, or faction shared owner.

I do suggest that someone makes a repo of the Keen code and removes the Timer, and instead has the Timer created by the MyAPIGateway to be able to keep track of Timer's so they and their events can be disposed of correctly when the game session is ended.

Yes, Keen have paused taking repos currently. I'm assuming it'll only be lifted after they get the new netcode in, because I expect some breaking changes to happen because of it, or at least a major reworking of the underlying codebase.

[midspace]

Keen's comments on Github Community contributions. http://forums.keenswh.com/threads/developers-note-development-progress-update-github-fixes-and-support-for-mods.7366068/

In case anyone missed it when it was posted.

[Spcemarine]

Does anyone have an idea what to do if a player modifies a ship by building blocks on it? I mean, is there a suitable way to:

1. prevent players from building blocks
2. prevent players from finishing blocks (the block might belong to the player if he does)

Concerning the first issue we might be able to do so by overriding the BlockBuilder and deactivate it if the player is not allowed to build on the grid found by FindClosestGrid(). I have to check if that really works but I think it might be possible. Regarding the second issue I was thinking about transferring the block ownership to the player who owns the most blocks on that grid. But I had to acknowledge that I cannot do that because there are no methods for that (if I didn't miss something). So I need another approach on that but I cannot think of something suitable (and possible).

[midspace]

Regarding the second issue I was thinking about transferring the block ownership to the player who owns the most blocks on that grid. But I had to acknowledge that I cannot do that because there are no methods for that (if I didn't miss something)

Looks like we can.

foreach (var grid in grids)
{
    var blocks = new List<IMySlimBlock>();
    grid.GetBlocks(blocks, f => f.FatBlock != null && f.FatBlock.OwnerId == oldPlayer);

    foreach (var block in blocks)
    {
        // Only change share mode for individual blocks
        var bl = (Sandbox.Game.Entities.MyCubeBlock)block.FatBlock;
        bl.ChangeOwner(newPlayer, shareMode);
        bl.ChangeBlockOwnerRequest(newPlayer, shareMode);
    }
}

[midspace]

I should note, I don't know the difference between ChangeOwner and ChangeBlockOwnerRequest. Both might be required. Or one should be used Client, and one should be user Server. More investigation required.

[Spcemarine]

That's very useful, thanks! The request uses the sync object of the cube grid and the other one just changes it locally, so I think we just need the request as anti grief for SP sounds like someone has schizophrenia or something. :D

[Spcemarine]

With the last commits the protection is ready to use but not really finished. There are still some ways to hijack a ship, e.g. we need to prevent players ramming into other ships in order to push them out of the protection area. Also I think most of the PvP issues must be solved on the client instance because turrets can shoot players (like the god mode sync issue). However this is not too difficult to achieve so it's not really important right now.