[PMC] Call for CTF Plugin Testers

[totemo]

I've rewritten the CutePVP plugin more or less completely and I need staff to volunteer to check it out.

 

I've installed it on [redacted], white listed and with most of the usual suspects on the list.  But let me know if you need to be added.

 

I've set up a condensed map for testing with two team bases quite close together.  In front of each team base is a flags area with two flags per team.  There are also two team buffs - beacons.  A team member can capture those for his team by clicking on them and they deliver potion effects to the whole team.  

 

The basics of the game are as follows:

• You're assigned to a team: red or blue.
• Red Team players wear red wool on their head, Blue Team players wear blue wool.
• Your name appears in the team colour in chat.
• When you walk on wool of your team's colour, it gives you a configurable buff (resistance).
• When you walk on wool of the enemy team's colour it gives you a configurable harmful potion effect (wither).
• You spawn inside your team base. Only team members can build in the team base region (red_base or blue_base, with configurable support for multiple regions in fact).  These are WorldGuard regions with the build allow flag set. The CutePVP plugin prevents enemy team members from editing in the region or hurting you in your own base.
• The flags are protected in WorldGuard regions that prevent all players from either team from editing.
• We also have the LWC plugin installed and players can lock their own chests.
• You steal an enemy flag by clicking on it.  This is recorded as a "steal" in your own personal score and the team score.
• If you are killed, log out, or type /drop, the flag is dropped on the ground.
• If you click on a dropped enemy flag, you pick it up again.
• If you click on your own dropped flag, you return it back to its home position and this is counted as a "return" in your personal and team's scores.
• You capture the flag (score) by taking it back to your flag area and clicking on one of those flags.  This is counted as a "capture" in your personal and team scores.  Your enemy(s) can prevent you from capturing by stealing all (both) your flags.
• You can see your score and that of the teams with /score.  Your score will also show you kills of enemy players.  You cannot harm your team mates.
• When you chat, it goes to your team members only.  To send global chats, use /g.
• Staff members: admins and mods in ModMode, will see team-only chats by both teams, as well as global chats.
• You can list all team members with /teams.
• You can get the coordinates of the nearest flag stolen from your team with /flag. Compasses also point to the same location.
• A dropped flag is automatically returned home after 5 minutes.
• If a dropped flag is moved in any way except by being picked up by a player (e.g. using a piston), that is detected and the flag is automatically returned home.
• Team buffs are captured by clicking on the respective beacon and last for about 30 minutes.  They can be stolen by an enemy team clicking on the beacon before that.
• Times, potion effects, number of teams and their names, colours and team protection options are all configurable.
• In addition to potion buffs/debuffs from the the team-coloured wools, this version of CutePVP supports "power blocks" which are blocks that confer configurable potion effects when walked on.  We'd like to keep the exact details of these a secret from players at this stage so that we have the option of them discovering the effects for themselves.  But in short, for you to test, the blocks and effects are:
  • diamond block - 10s of jump boost 10 - for scaling the walls of enemy bases ;)
  • gold block - 10s of regeneration 1
  • emerald block - 10s of confusion 3
  • iron block - 10s of damage resistance 1 - same as the wool - maybe change
  • ice - 10s of speed 2
  • quartz block - 10s of invisibility
  • glowstone - 10s of fire resistance
  • coal block - 5s of blindness
  • orange stained clay - 10s of health boost 2 (4 extra hearts max health)
  • yellow stained clay - 10s of poison 4
  • purple stained clay - 10s of night vision - may need to be longer - sort of flashes as if the potion is wearing off the whole time
  • black stained clay - 10s of weakness 2

The idea is that players can exercise their creativity to build base defences with these blocks to their advantage and their opponents disadvantage.  The above blocks apply their effects equally to both teams.  I've been given a suggestion to track which team placed the blocks and always make them work to the best advantage of whoever placed them, rather than either way.  I'll look into it, but if it is in any way complex to implement I probably won't have time to do it.

 

The above list should suggest a range of things that you need to test.  At this stage, I expect there to be some minor difficulties with ModMode and or staff type commands. The biggest issue I still have in this area is exemption from team assignment, which mainly applies to ops (I've removed the admin exemption for now), so for this reason I have cleared the ops list on that server.

 

The other work that remains to be done is:

• Automatically assigning IP alts to the same team.
• Adding the option for coloured leather kits and other items when spawning.
• Fixing the way the plugin's reload command handles team membership (just don't play with it).

I'm also keen to experiment with using the Citadel plugin (http://dev.bukkit.org/bukkit-plugins/citadel/) for protections, subject to time constraints.  The way that would work is that I would disable WorldGuard protection of bases, and possibly LWC too.  Players would then use Citadel to reinforce their builds (base spawn area and fortifications outside the flags area where all edits are denied by WorldGuard).  Citadel allows players to reinforce blocks with one smooth stone, iron or diamond per block or container (chest). The value of the reinforcement material determines how many times someone must break the block before it finally actually breaks.  Diamond reinforced obsidian takes many hours to break under this scheme.

 

Edited April 21, 2016 by Barlimore
Redacted server connection information.

[JohnAdams1735]

As a followup, I propose Friday, September 6 at 6pm EDT/3 PDT. Convert this to my timezone. It's early enough (sort of) for the EU and UK, but not too early for Australia and New Zeland. It's up for negotiation maybe an hour or two in either direction, though 11pm in London is already a bit late.

 

We'll announce it as lasting 24 hours from when it begins, but if people are still having fun at the end and there's at least two or three staff around with me (including a tech), I'd be happy to let it run longer. I can personally plan to be there at the start and the end (extended if wanted) at the very least, but most likely I'll be able to be around for several hours of it.

[tompreuss]

We also have the LWC plugin installed and players can lock their own chests.

A suggestion if possible to implement at this stage would be to auto add players on each team to groups g:red and g:blue and to auto-lock placed chests to those groups. Last November we didn't use LWC (so we did things like place blocks surrounding chests to protect them from theft) but this past attempt we did have LWC and locking things to different people/groups was cumbersome and difficult to coordinate, especially with such large teams.

 

Those look like penises. Well done.

[Denevien]

As a followup, I propose Friday, September 6 at 6pm EDT/3 PDT

 

Just as to not shoot ourselves in the foot, make sure we do not announce any kind of date/time until every aspect is tested and ready to roll out in full. Don't announce when we're 80 or 90% done, and plan to be done by go time. We've had too many things pop up last minute over the years causing trouble. The only thing we should have left to do before we announce is to remove the whitelist.

[Tharine]

• Staff members: admins and mods in ModMode, will see team-only chats by both teams, as well as global chats.

I just wanted to clarify, will this be on for admins all of the time, or just admins that are using ModMode?

[totemo]

 

• Staff members: admins and mods in ModMode, will see team-only chats by both teams, as well as global chats.

I just wanted to clarify, will this be on for admins all of the time, or just admins that are using ModMode?

 

 

 

My intention was to have the admins as "always on" staff, exempt from team allocation and to set up the moderators so they can play the game, and only see all the team chat when they enter ModMode.  A couple of years ago when we ran this, moderators had no moderation powers during the event, which I found frustrating as a moderator because there seemed to be a lack of responsiveness from the admins at the time.  That event was plagued by a several problems (apart from the usual first few hours where the plugin was usable): lack of ModReq, griefers (potentially enemy team alts) raiding team chests.  I'm keen to fix as many issues as possible with that.

 

I think I can set up the permissions so that admins can choose to be allocated to teams anyway, still see all chats, and use ModMode for official duties (and in ModMode, the helmet would change the helmet to a different block to indicate staff status - though perhaps not essential since we usually vanish anyway).

 

Does that sound like something you would want?

What were your expectations as an admin, in terms of being able to play?

[totemo]

A suggestion if possible to implement at this stage would be to auto add players on each team to groups g:red and g:blue and to auto-lock placed chests to those groups. Last November we didn't use LWC (so we did things like place blocks surrounding chests to protect them from theft) but this past attempt we did have LWC and locking things to different people/groups was cumbersome and difficult to coordinate, especially with such large teams.

 

Omission of LWC at this stage was an oversight on my part.  We can do that, more or less.  The g: syntax indicates a permission group, but I'm not allocating players to permissions groups when they're on teams.  Given how unreliable bPermissions has been lately with ModMode, I think it would be tempting fate to do so.

 

I would probably change the (primary) base region names in the configuration file to red and blue (from red_base, blue_base) and then use the WorldGuard API to add members to those regions.  Players could then /cprivate r:red, much like they do on PVE currently.

[JohnAdams1735]

My intention was to have the admins as "always on" staff, exempt from team allocation and to set up the moderators so they can play the game, and only see all the team chat when they enter ModMode.  A couple of years ago when we ran this, moderators had no moderation powers during the event, which I found frustrating as a moderator because there seemed to be a lack of responsiveness from the admins at the time.  That event was plagued by a several problems (apart from the usual first few hours where the plugin was usable): lack of ModReq, griefers (potentially enemy team alts) raiding team chests.  I'm keen to fix as many issues as possible with that.

 

I think I can set up the permissions so that admins can choose to be allocated to teams anyway, still see all chats, and use ModMode for official duties (and in ModMode, the helmet would change the helmet to a different block to indicate staff status - though perhaps not essential since we usually vanish anyway).

 

Does that sound like something you would want?

What were your expectations as an admin, in terms of being able to play?

 

I personally wouldn't mind having admins always able to go into a modmode sort of thing and that moves them into a neutral "team." However, the last time we did CTF we had at least one staff member around the entire time. And the time before that I was up the full 24 hours, so sorry if I wasn't very fast :p

 

The idea originally was for mods to be able to play and not have to worry about doing anything mod-related, but mods being able to use modmode should be fine. We had modreq last time, and as I recall we had at least two staff members who kept on top of the modreqs for most of the time.

 

Not that I don't trust the staff, but having a 100% neutral staff team is nice. I, for one, plan on moderating the whole time, and I had a list of about 5-7 mods who were willing to moderate the entire time as well, or if they wanted to play, would do so on an alt. They represented the North American and UK time zones. And I would post again asking for more volunteers.

 

I think the idea also was not having to worry about getting modmode to play nice with CutePVP, but totemo, if you are willing to tangle with that and get it done in a timely manner, more power to you.

 

LWC and people being able to set permissions to chests based off teams would be great because, yea, having your teams' chests raided sucked.

[JohnAdams1735]

Just as to not shoot ourselves in the foot, make sure we do not announce any kind of date/time until every aspect is tested and ready to roll out in full. Don't announce when we're 80 or 90% done, and plan to be done by go time. We've had too many things pop up last minute over the years causing trouble. The only thing we should have left to do before we announce is to remove the whitelist.

 

Yes, of course. That's one of the reasons it's Sept. 6 and not Aug. 30 - to give totemo and testing things more time. I'm just suggesting the date and time as a goal for us to work towards, keeping in mind I want to announce a week in advance. So to meet the Sept. 6 goal, we need to be, as you said, 80-90% done by Aug. 30 or 31. I have the announcement post all ready to go - all that needs to be added is the date :)

[Tharine]

My earlier curiosity about the situation regarding seeing all realms of chat as an admin stems from the fact that I would like to be able to moderate where possible, but not have my gameplay affected by the fact that I could at any time accidentally glimpse a coordinated attack by the other team and be given an unfair advantage in doing so. I'm not worried about my ability to act fairly, but it does ruin your fun a bit to know that there's something coming and you can't do anything about it because you were unintentionally privy to that knowledge. totemo and I have worked out that an easy solution is to simply put me into the moderator permissions group for the CTF event, which i'm quite happy with as it means I should still be able to moderate where necessary.

[MasterCommaThe]

It's silly, but can we have the base shoot off fireworks when a flag is successfully returned?

[totemo]

It's silly, but can we have the base shoot off fireworks when a flag is successfully returned?

 

I like silly ideas like that.

 

 

The CTF testing is temporarily down while the P admins take a look at a map they're making.

 

It will be back up in a day or two with new features in the plugin and some issues resolved.

[totemo]

Some plugin issues are resolved.  Some still to do.  I will set up another round of testing in probably 24 hours.

 

In the mean time, there are action items for event preparation here: https://nerd.nu/forum/index.php?/topic/472-moving-forward-preparations-for-ctf-take-2/page-2#entry5521

[BeastBruiser]

Yes, of course. That's one of the reasons it's Sept. 6 and not Aug. 30 - to give totemo and testing things more time. I'm just suggesting the date and time as a goal for us to work towards, keeping in mind I want to announce a week in advance. So to meet the Sept. 6 goal, we need to be, as you said, 80-90% done by Aug. 30 or 31. I have the announcement post all ready to go - all that needs to be added is the date :)

I believe Denevien is suggesting that we need to be 100% done before announcing it. Having any surprises with plugins(or unexpected RL circumstances) causing a delay would definitely infuriate some of the playerbase(as displayed last time)

 

better to be 100% and a week later than risk a consecutive snafu with CTF IMO

[MasterCommaThe]

Do we want to schedule a definite time for admin & mod playtesting prior to the event? Must be prior enough to resolve any bugs that are identified during the testing.