[Addition] Advanced Disk Drive

Crafted just like the rest with gold, but allows a programmer to create read-only files :)/> OR settings to allow the "run startup" to be disabled on the disk drive, so startup on a computer would run, but one on the disk drive wouldn't run unless explicitly run from the command line :)/>

Just a thought, I know there can be downsides to both versions, but its food for thought, maybe u can think of a way to prevent downsides to these. :)/>

Not run startup from that drive? Do not place such file.
Read-only files? Not needed really.

May be better idea would be switch on Disk Drive to read-only mode? To forbid to change disk content.

May be better idea would be switch on Disk Drive to read-only mode? To forbid to change disk content.

perfect

Sebra, on 21 December 2012 - 03:58 AM said:

Not run startup from that drive? Do not place such file.

I don't think you quite understand me. Currently a startup file on a disk overrides a startup file on the computer, I pose another 'switch' that disables that feature and makes the computer on startup ignore any startup files on a disk and bootup instead from the startup on the computer.

Sebra, on 21 December 2012 - 03:58 AM said:

May be better idea would be switch on Disk Drive to read-only mode? To forbid to change disk content.

Sorry I didn't communicate my idea well enough, thats actually what I meant

The first feature provides the all-new feature of permanently bricking your computer (though you can already come pretty close to this by programming your computer to rename disk/startup on detecting a drive, this just makes it easier to end up in decorative block land).

I'm not sure what the latter feature provides.

The way to perform the second part of this suggestion is to insert the disk after the computer has started up. Another way is to not include a disk/startup, as has been previously mentioned by other posts.

JJRcop, on 22 December 2012 - 06:06 AM said:

The way to perform the second part of this suggestion is to insert the disk after the computer has started up. Another way is to not include a disk/startup, as has been previously mentioned by other posts.

I think the point he's getting at is more for servers where people use computers for password doors and disable ctrl+t if you place a disk in a drive next to the computer with a file on it called startup they can override the security and enter the house or what ever your trying to protect,

creating an over ride disk is really easy as well it just needs a file called startup with return written on the first line and its done

The startup file simply needs to exist; it does not require any contents.

We do need something to protect computers, bu allowing the rightful user, in case of serious problems, to reboot said computer using the standard startup from the rom. Basing this protection on block access such as a disk drive…it's incomplete because of turtles.
Basing it on screen access would make it difficult to allow external users to interact with programs. I support one of Orwell's post's, that would allow to set a bios password. Now that I think about it, to ease use, this password would only be able to be set the first time by the original placer of the block.

TheOriginalBIT, on 21 December 2012 - 12:57 PM said:

Sebra, on 21 December 2012 - 03:58 AM said:

Not run startup from that drive? Do not place such file.

I don't think you quite understand me. Currently a startup file on a disk overrides a startup file on the computer, I pose another 'switch' that disables that feature and makes the computer on startup ignore any startup files on a disk and bootup instead from the startup on the computer.

Sebra, on 21 December 2012 - 03:58 AM said:

May be better idea would be switch on Disk Drive to read-only mode? To forbid to change disk content.

Sorry I didn't communicate my idea well enough, thats actually what I meant

My native language is not latin, but… What is your main language?

In attempt to make impossible to "brick" Computers, Dan200 made them vulnerable to external Disk booting. Making some Disk Drive to not support booting will not help as it can easily substituted by basic supporting one.
I suggested better way (imho) but Dan200 prefer his way. He has full right to do so.

If you've placed your computer so that it is possible for someone to put a disk drive next to the computer and then still access the computer, they can just as easily remove the computer and replace it with their own, programmed how they like. You need to recess your computer and place a wooden pressure plate underneath where it will drop if broken, so you can activate a deathtrap on the vandal (the blocks in the wall around the computer are redstone conduited so that breaking them also activates the deathtrap).

That means that the only option for rebooting that computer using a startup disk is to place the drive, insert the disk, and go far enough away for the computer's chunk to unload, then return. That's plenty of time for the computer to discover and delete/rename any disk/startup if there isn't supposed to be one.

You leave yourself with physical access to the back of the computer, behind the security wall. That way you, the user, can reprogram the computer if necessary. Without having the computer magically know it's owner from everyone else.

ChunLing, on 22 December 2012 - 10:51 AM said:

You leave yourself with physical access to the back of the computer, behind the security wall. That way you, the user, can reprogram the computer if necessary. Without having the computer magically know it's owner from everyone else.

Since that last remark seemed directed to me, here's my reply:
That method does not work for turtles. Given that turtles are very destructive, boot protection for turtles should be part of any attempt to make ComputerCraft grief-secure.
About magic: most protections are magic, in that sense. But the way I described it, magic would be only there to prevent griefers from setting a password for the first time; after the password had been set for the first time, the magic would disappear. You could always throw the magic out of the equation by emulating normal bios passwords, i.e. no caring about whoever is setting the pass (but you would have to have the previous pass).

Turtles should be vulnerable to being stolen, it helps alleviate their overpower factor.

ChunLing, on 23 December 2012 - 12:52 AM said:

Turtles should be vulnerable to being stolen, it helps alleviate their overpower factor.

I guess that's a way to view it… but then who handles the mess caused by people being careless with them and then griefers getting access to them? I was thinking of preventing the mess before it happened, instead of relying on people.

The entire point of "griefing" is to use the mechanics that have been supposedly set up to make it easier to "play nice" to play dirty.

Every game mechanic that provides an advantage to those who play nice, without any exception, has proven more of a boon to griefers. The only way to deal with griefers is to either bar those who don't play nice from participating, or to just not bother trying to encourage playing nice.

I thus categorically deny the validity of any appeal to a game mechanic as being a good way to prevent griefing.

But, in terms of the specific question at hand, making it more difficult to steal/subvert a turtle that has entered your area is a huge benefit to griefers, not to people playing nice.

ChunLing, on 23 December 2012 - 03:59 PM said:

I thus categorically deny the validity of any appeal to a game mechanic as being a good way to prevent griefing.

I do not agree with your view about griefers, because you seem to say that you don't even care about preventing griefing happening? So, you are against chest protections, ect? And in general about coded rules?

ChunLing, on 23 December 2012 - 03:59 PM said:

But, in terms of the specific question at hand, making it more difficult to steal/subvert a turtle that has entered your area is a huge benefit to griefers, not to people playing nice.

Well, protecting the bios does not interfere with the ability to stop said turtle. You can just shut it down, and even break it if block protections aren't active. You just aren't able to peek inside and mess with it's data, or use it for yourself.

Yes, both of which reduce the disincentive for someone to try and use a turtle to remotely grief your town/base/whatever.

Being able to remotely grief with no chance of having it tracked back to you is probably not a huge disincentive.

And the whole history of griefing, the entire origin of the term, was from the abuse of game mechanics intended to prevent PvP play. When the entire behavior consists exactly of abusing mechanics intended to prevent people from not playing nice, what makes you think that there's some magic game mechanic that can't be abused?

You either permit players to interact or you do not permit players to interact. Having only single-player game modes is a way to prevent griefing, but if you are going to allow multi-player then you can't be bothered about griefing, only about balance.

CoolisTheName007, on 23 December 2012 - 09:11 PM said:

ChunLing, on 23 December 2012 - 03:59 PM said:

I thus categorically deny the validity of any appeal to a game mechanic as being a good way to prevent griefing.

I do not agree with your view about griefers, because you seem to say that you don't even care about preventing griefing happening? So, you are against chest protections, ect? And in general about coded rules?

I think he isn't too far off, being an experimental griefer myself I know first hand how useful so-called protection is… that being said I think grief protection should be implemented if possible as any griefer who is actually interested in the game in any way at all does it for the challenge, the thrill and for stealing other peoples' stuff

KaoS, on 24 December 2012 - 12:12 AM said:

I think he isn't too far off, being an experimental griefer myself I know first hand how useful so-called protection is… that being said I think grief protection should be implemented if possible as any griefer who is actually interested in the game in any way at all does it for the challenge, the thrill and for stealing other peoples' stuff

I'm slightly confused. Do you mean that increasing protections raises the fun-meter for griefers?
EDIT: yeah, that was it (confirmed over IRC).

ChunLing, on 24 December 2012 - 12:11 AM said:

snip

I understand your point of view, which is PvP centered. However, there are many non-pvp servers (I will discuss this kind of gamemode in the rest of the post), where it is essential to allow new players to join; as much as admins require complete applications and do background checks, one can never be sure of the new members intentions. Consequently, it is of the most importance to prevent griefing. This is done retroactively by associating a player to each action (placing a block, changing a block, ect) and registering that action in a database for further analysis, or actively by restricting some actions to certain groups of players. As you can see, there's always the need for magically associate a player id with in-game actions.
Plus, there is the case of game automatons, such as mobs, npc's, nuclear reactors and all other game mechanics that can significatively damage other's property, without direct intervention of the player (e.g. a delay, or they wait for pre-conditions, ect, but they can be someone's fault, normally the block placer).

ComputerCraft has features that require protection of some kind. Computers/turtles can perform actions on their own, and so fit the automaton category. One can perform damage either by:
-accessing a terminal: block protection can protect the terminal; but one may want to allow access to the terminal for interaction, without risking the player who is accessing to reprogram the turtle. Thar leads me to the next method of performing damage:
-reprogramming a previously existent turtle: one can protect the turtles/computers from being hacked by others by allowing bios passwords, and that can be done by a Lua replacement of the shell program. However, magically allowing only the block placer to set the password for the first time would be better (otherwise it would be a way to grief less informed users).
-using the turtle/computer (with peripherals) to perform damage via player-like actions: the only way I see for restricting automatons in general is to let labelled computers/turtle get their own permission set, which the peripherals then inherit. Players should be able to set/un-set permissions to automatons as they do to other players. Plus, for retroactively looking up whose fault some action is, this inheritance should keep track of who gave which permission.
-using the turtle/computer to perform damage via less than efficient programming (rednet spamming, ect): (optional) this can be prevented by doing a check on the player's ability to program, and I know of at least one server who enforces it, via a whitelist for CC for which you have to pas a test first. But they still use a very old version of CC, and probably that's why they need to do it.

If they get implemented, it will become much safer to deploy CC systems (e.g. computers with some program) at no risk.

I do know that permissions are still very fresh (or not existent), but if they are to be implemented, what do you think about these methods?

I would like to point out that disabling startup files on a disk drive does not make it possible to brick the computer, as you could just break the disk drive and replace it with a normal one that does allow startup.

True enough, unless some kind of block protection is enabled.

I'm not saying that anti-griefing measures can't be taken, but they cannot be achieved through game mechanics. A game mechanic, something that applies to all players who are not operators, by it's very nature cannot give "nice" players an advantage over not so nice players.

Whether someone is "nice" or not is a human judgment, it cannot be reproduced mechanically. So arguing for your proposal based on the idea that it will allow a mechanical distinction to be made between "naughty" and "nice" is invalid, it is like arguing for adding a feature that will allow the player to teleport themselves to IRL work, shopping, etc. (so they save time in real life and can play minecraft more, of course).

No matter what the feature is, the minute you start saying that this will make it possible for players to teleport IRL, I…am just slightly less incredulous than I am about the claim that you can prevent griefing with a new game mechanic.

The OP did not say anything about griefer protection. Any discussion about griefer protection is off-topic here.

ChunLing, on 24 December 2012 - 05:47 PM said:

True enough, unless some kind of block protection is enabled.

I'm not saying that anti-griefing measures can't be taken, but they cannot be achieved through game mechanics. A game mechanic, something that applies to all players who are not operators, by it's very nature cannot give "nice" players an advantage over not so nice players.

Whether someone is "nice" or not is a human judgment, it cannot be reproduced mechanically. So arguing for your proposal based on the idea that it will allow a mechanical distinction to be made between "naughty" and "nice" is invalid, it is like arguing for adding a feature that will allow the player to teleport themselves to IRL work, shopping, etc. (so they save time in real life and can play minecraft more, of course).

No matter what the feature is, the minute you start saying that this will make it possible for players to teleport IRL, I…am just slightly less incredulous than I am about the claim that you can prevent griefing with a new game mechanic.

Whether or not a player is nice or bad/ a griefer is up to operators, and since there is a general consensus in non-pvp about what is bad or not, it is possible to analyze them /detect them /prevent them mechanically. Also, in non-pvp, it is normal to code the concept of property. If you own something in that way, no-one else can use it; in PvP, there may be something as trying to be responsible for your belongings, but in non-pvp, people don't want to care much about protecting their stuff because that's the gamemode they choose; they only want to do the essential to protect themselves from griefers. And that's why owning something in non-pvp is magically coded in. A griefer can protect his belongings, and certainly may steal other's unprotected belonging's and protect them in his name, but that is certainly better than having no protections at all.

The OP proposed a new disk drive that would either allow read-only files or disabling running a startup file on such disk when booting an adjacent computer. While the first one seems extremely oriented to protecting data and is strongly related to avoiding griefing, the second one requires some strange configurations for it to be useful for protection, like having block protection on all blocks surrounding the computer, but non-protected access to said blocks inventories. Maybe the OP did want something different for the second suggestion, but I took it my way.

In CC, owning a computer is still impossible; a simple solution would be allowing the rightful owner to choose the startup file via a password protected bios (as Orwell suggested). By using proper programs, the terminal could be accessible to others without interfering with the program except in one way, that would be shutting down / re-starting the computer (even then a proper program could decide not to do anything); that is acceptable in no-pvp because it is common rule to always have a way to shutdown other's automatons (factories, turtles, ect.).


Bricking a computer, in the sense the computer can only be shut down/re-started by others than not the owner, is necessary for proper griefer protection, together with not allowing block breaking of the computer/turtle by others.

immibis, on 24 December 2012 - 08:43 PM said:

The OP did not say anything about griefer protection. Any discussion about griefer protection is off-topic here.

Griefer protection is related to the OP. Any normal discussion diverges some amount from the OP.

Just to get this straight, do the various block protection mods/modes available simply not work with CC at all?

If people want to be able to use block protection mods with CC, and CC isn't allowing it in any way shape or form, that's a different issue (on which I do not have an opinion one way or the other).

I'm thinking of the case of the basic CC mod, which doesn't currently incorporate any block protections for any other blocks.

They may work (I think they do), but they are incomplete for a mod like CC; e.g. one may want to expose the terminal, but not give breaking rights (that may already be possible, not sure), but turtles being represented all by one fake player as it was in some protections mods is certainly far from ideal.
This may or may not be something that falls necessarily into CC hands, but in general one discusses what can be done to give more protection, and secondly who can do it, or where it should be done.