The default robot name format is <name of player that placed it>.robot, it can be changed in the config. You can set that to a static value (e.g. 'OpenComputers') to change robots' global permissions.

Not sure about the robot.use() thing, can you give me an exact description of what they do and how it differs from what a player with their level of permission could do? Thanks.

Thanks for the quick reply.
But now is the problem to include an not exsisting "player" to the perm system if I set it to a static value.
I'll try one or the other.
And the thing with the use is, a robot can make a right click at fields to harvest or with suck() to chests and put sth. in. May it's because the perm.sys. can't check that realy.
If I do an right klick as Default group (without any permissions) I can't trick the system.

Hmm, well I'm not an expert with permission systems in general, I only tested it with WorldGuard and that worked perfectly fine.

As for the suck/drop stuff, good point. I'll try adding an "interact" event before doing that when I have the time, hopefully that can be used as a valid test.

I'm also not the best one, but I'll give my best.
May thats a big problem for all bigger servers, with a permission system.
If I find an solution for the including of the Robot in the system I will post it.

I did some (very limited) testing, and from what I can tell, setting a region as owned by someone doesn't protect chests normally, either (WorldGuard, /region define blah or what it is). I.e. I could interact with inventories in a region I wasn't an owner of (as non-op). Consequently the standard 'can player interact with block' event didn't work, either.

To be honest, I'm not sure that's the proper way to approach this anyway, since there are just way too many special cases. I suppose the 'cleanest' solution would be to not allow robots to move into owned regions? Not sure how to best check for that without potential side-effects, though (i.e. I don't know what sending a PlayerInteractEvent with Action.RIGHT_CLICK_BLOCK - which is what's used for block placement checks - could potentially undesirably trigger, when used to check for 'movement' of the robot).

If someone more experienced with coding for permission systems sees this and has some input on this, that'd be great.

Maybe it could be an idea to have a config option to drop the ".robot" suffix in the config file, so the robot operates under the same name. Or is that impossible to implement since that playername might already be in use, but a wrapper for the permission system maybe....

That's already possible, the name pattern for robots is configurable via the setting nameFormat.

I'm just keeping this open as a reminder to look into prohibiting robots from moving into areas they should not be able to edit (since, by moving in there, they basically are, seeing as they are blocks).

Having had another look I don't think there's an ideal way to solve this from my (purely Forge reliant) side. As also mentioned in #656 I think it would be better if someone wrote a Bukkit plugin that maybe uses the robot events to make the robots behave better in a Bukkit environment. I have no experience with Bukkit plugin development and don't plan to start it, but if someone does attack this and needs me to add something within my capabilities to OC I'd be happy to help in that capacity.

I have the same issue, the only way to get it to break/place blocks is to disable ModifyWorld (a dependency) for PermissionsEx. I currently run Essentials, LWC, PermissionsEx and GriefPrevention. I went through the list disabling every one of them one by one until I determined what it was. Please note this should NOT be performed on a production server unless you have another mod/plugin to disable certain blocks.

@shortybsd And it doesn't work to set
nameFormat="$player$"
in opencomputers config instead of the default
nameFormat="$player$.robot"
?