[AC] Additions to Creative

[Dumbo52]

There are a couple of small ideas for Creative that have been proposed, but no action has been taken on them yet. I'd like to use this thread to facilitate discussion of these ideas (particularly between the Creative and tech admins, though others' opinions are certainly welcome) so that they can actually see some daylight and (possibly) be implemented on C.

 

A good portion of Creative players have been asking for the /hat command for a while now; is there any reason not to allow default players to use the command? I had been told a while ago that it couldn't be enabled due to the possibility of player data corruption, but I haven't been able to figure out how this is able to lead to data corruption any more than the /i command is. I've also talked with a couple of techs now who haven't seen a problem with it. Is there a basis for this concern, or are hats safe? If they are safe, I think we should enable the /hat command on C.

 

The idea of command blocks has also come up. The proposal is to allow admins to place command blocks at players' requests on C; after receiving a request, the admin would evaluate the command to determine whether it's appropriate or not. The main reason for enabling this would be to give players' builds another level of functionality, particularly for use in "test"-like builds which require the player to pass through a series of challenges. For example, someone might want to give an item to or play a sound for a player once they reach a certain spot. We would only allow certain commands to be used, of course; I'm thinking we would allow commands such as /effect, /give, /playsound, /tell, /testfor, and /tp. Additional conditions would also need to be met, such as specifying only a limited range of players and being connected to 'reasonable' redstone (e.g. not a clock such that the player's inventory gets filled to capacity). In general, though, command blocks would be evaluated from a holistic standpoint, in reference to how it is used.

 

I spoke with LadyCailin a couple of days ago, and it sounds like one concern with this idea is containment. For example, once a command block is placed, how would we assure that the surrounding redstone is not changed in order to utilize the command block in a different way than was originally planned? The idea of using EasySigns as a replacement was proposed as a replacement: As I understand it, they could be bound to buttons, pressure plates, and levers to trigger an event. While this would evade the problem, the signs would also prevent events from being triggered dynamically at all and would only trigger events upon direct interaction with the player. However, this situation would in part eliminate one of the uses of command blocks -- to dynamically run commands based on redstone input.

 

A more desirable solution, I think, would be to use the existing tools we have at our disposal. Before placing a command block, we check the redstone to ensure that it is reasonable and doesn't do anything unwanted. The entire area of contiguous redstone would then be protected with a 2-block buffer, with no owners or members. This would prevent anyone from editing the redstone after the fact; if the builder does request to edit the area again, the command block will need to be removed and requested again after the player is done editing. This process has the potential to be a bit of a hassle, but it would ensure that command blocks are safe and do only what they were originally intended to do.

 

Feedback on these ideas would be appreciated. They're not huge changes, but I think they might bring a bit more to Creative that people have been interested in seeing.

[Mumberthrax]

I think protecting the redstone circuit is really a very simple and effective solution to the question of tampering with the circuit to abuse the command blocks. If there are no concerns about this or objections, I think it should be implemented.

 

regarding /hats - hearing from techadmins seems like the best thing here. Which plugins provide this command on nerd? Are there other plugins that usually offer this feature which might not have the same stability issues?

[kitcatbar]

I think protecting the redstone circuit is really a very simple and effective solution to the question of tampering with the circuit to abuse the command blocks. If there are no concerns about this or objections, I think it should be implemented.

 

regarding /hats - hearing from techadmins seems like the best thing here. Which plugins provide this command on nerd? Are there other plugins that usually offer this feature which might not have the same stability issues?

 

Are there stability issues? P and C (and maybe S?) ran it for Halloween, and I don't remember any issues then.

[tompreuss]

Are there stability issues? P and C (and maybe S?) ran it for Halloween, and I don't remember any issues then.

 

The C /hat is currently as follows:

*:/hat [$data] = >>>
    _assertperm('admin', 0)
    if(equals(pinv(player(), 103), null), 
        set_pinv(array(103: array(type: if(equals($data, ''), 298, $data)))),
    #else:
        set_pinv(array(103: null)))
<<<

The one we used on P/S for halloween was "/wear" and actually required the item to be held in hand, and was on removal was returned to the player (so as to be survival mode friendly).  So no need to worry about odd things being put in that slot I guess, only normal obtainable items.  

 

Yeah, we'd need a tech to weigh in on if the C one could be opened to defaults, my guess would be we might need to make sure there's nothing that when worn on your head could mess up yourself or others or the server.

[LadyCailin]

I see no reason at all not to enable /hat for creative. I know of no issues that that can cause at this time, there are several servers that do that all the time, and I've never heard of anyone having issues.

 

As to the command blocks, I'm still 100% against them, but I'm working on and have mostly added a redstone_changed event in CH, which can be used to detect redstone events and then run any CH script we want. This would work like EasySigns in that admins must configure it, but once configured, the full power of CH would be available, including the existing EasySign triggers. There is no real need for command blocks, if you think about the final end goal, and the goal can be reached in a much safer and straightforward way via other methods than command blocks, hence my objections to them.

[marting11]

I see no reason at all not to enable /hat for creative.

It's basically just for fun. For example there is no "real reason" to have a /drunk command either.

Another simple change that I think we all agreed to is to enable back /me on Creative.

Last C meeting notes :

https://docs.google.com/document/d/1AKq6eDHqq3oExSYrujcV0C9rJLotqePaVKgY2DHkHxo

[tompreuss]

I see no reason at all not to enable /hat for creative.

It's basically just for fun. For example there is no "real reason" to have a /drunk command either.

Cailin is supporting the addition of /hat, she just used a double negative.

[marting11]

Cailin is supporting the addition of /hat, she just used a double negative.

Oops, sorry about the confusion.

[Mrloud15]

Closing and moving to the archives.