redwall_hp
-
Posts
454 -
Joined
Content Type
Profiles
Forums
Events
Posts posted by redwall_hp
-
-
onChunkUnload() was called about 600 times, averaging 0.01ms per call in one of the more recent timings that you guys linked: http://timings.aikar.co/?url=12629871. You were saying that you saw an 11,000ms chunk unload event. It's really strange that this doesn't show up on the timings. 11000ms/600 = 18.3 ms. A single bad event should have a noticeable effect on the average.
One would assume. Then there's this timing: http://timings.aikar.co/?url=12629871
High load, lots of red events for entities and mob AI. But the average tps during the sample is still over 19. Usually when that happens, TPS drops significantly.
-
Ban information:
<ModReq> Ban for LavaCakeLover on c.nerd.nu for AFKing at zombie spawner, with excessive mobs, after multiple warnings. nerd.nu/appeal by redwall_hp on 2015-10-01T08:12:35.113
<ModReq> Note #42251 for LavaCakeLover on c.nerd.nu: Warned twice for AFKing at grinder, >600 mobs. by Sapphric on 2015-10-01T05:20:12.903
The rule you broke: "No inducing excessive lag. In particular, do not allow huge numbers of entities to build up, e.g. by idling at a non-kill mob grinder or breeding an absurd number of animals."
The first two times, we recorded over 600 zombies sitting in your grinder, causing noticeable lag. This most recent time, it was closer to 300.
In the future, please avoid doing this or it will be dealt with more severely.
Since the grinder appears to be attached to this base, I recommend that it be altered to either:
- Have a killing device to keep the zombies from stacking up and collect items with hoppers. (This could have a switch to disable it for when you want to actively use it for XP.)
- Have lights in the spawning chambers, so mob spawning can be disabled with a switch when you're not there to attend to the grinder.
Unbanned, and welcome back.
-
Since there have been observations that spikes may correlate with players joining, more specifically joining on unloaded chunks, here's a list of every plugin that registers an on-join listener. (As reported by a plugin with an on-join handler with MONITOR priority.)
ProtocolLib, bPermissions, SBC, CommandHelper, OpenInv, NoCheatPlus, NoCheatPlus, NoCheatPlus, NoCheatPlus, VanishNoPacket, Multiverse-Core, WorldGuard, WorldGuard, CobraCorral, ModReq, NerdSpawn, CommandHelper, AsyncWorldEdit, ModMode, VanishNoPacket, LolNo, LWC, ProtocolLib, LogBlock, NerdList, dynmap, dynmap, notifyshit, KitchenSink
And the quit listeners:
CommandHelper, ModMode, KitchenSink, Multiverse-Core, CobraCorral, CommandHelper, CommandHelper, TPControl, AsyncWorldEdit, VanishNoPacket, LolNo, ClientPermissions, LWC, ProtocolLib, StandMaster9000, LogBlock, dynmap, notifyshit, OpenInv, NoCheatPlus, NoCheatPlus
-
This timing is from a few nights ago, during off-peak hours: http://timings.aikar.co/?url=12601271
12 players online, still lag spikes.
-
I'm not sure what triggers that particular message or where they learned to spell "amount" but can we run for a while without DynMap to see what effect that has.
We ran it with dynmap disabled for a few days before the livemap was made public. It didn't make a difference to the lag spikes. -
Here are Spigot timings with around 50 players online: http://timings.aikar.co/?url=12622106
Note that the lag spikes occur even when there are more like 10 players on, when most of the flagged values are reasonably low. (Will post a timing from off-peek hours later.)
Edit: And here's c45y's latest graph of the BungeeCord GC.
-
I just lowered -XX:G1HeapRegionSize to 4M. C45Y's still running the graph, but initial report sounds like it's smoother.
-
As Dumbo announced on the subreddit, the game servers and everything else will be going down for a few hours on Saturday, September 26 at 8AM EDT. This maintenance period is for the replacement of our SSD. We expect to have everything fully operational by 2PM EDT on the same day.
-
6
-
-
A ticket has been opened, and the provider agrees that the drive needs to be replaced. Details haven't been hashed out yet, but the process has started.
We've got a timetable we're aiming for ourselves, but we don't want to announce it yet since we have no idea if the provider will be okay with it or not. Basically, 10PM Saturday my time (so early morning Eastern) we want to run down our preparations and have the server powered down for service by the following hour. Then they have a four-hour window where they'll get to it and perform the repairs. But we don't want to announce anything until we have confirmation that it's acceptable with the provider.
So, don't go around telling people this date, because if things fall through and we have to change it, the unnecessary fallout will be annoying. (People already are irritable enough about the lag.)
Once we've got the schedule set in stone, we'll ensure there's an announcement on the subreddit and forums, tweet it, and change the server MOTDs. Hopefully there will be a few days of lead-up time, but it's not the end of the world if notice is a little short, since the plan is for a reasonably off-peak time.
-
2
-
-
Well, Dumbo figured out that there's a 4 hour hardware service window, so it seems like it would be wasteful to set everything up on the other server and deal with updating DNS, only for a four hour downtime.
A better strategy is:
- Put the word out that we'll be having a scheduled downtime on a certain day
- Back up the SSD
- Power down for service
- Wait until it's done
- Copy everything from the backup to the new SSD, make sure everything's working, and unwhitelist
We'd lose the website during the four hour window, but reddit, Mumble (which is hosted elsewhere) and IRC would all be available still.
-
Will there be bedrock on the bottom layers of the asteroids, or can people mine through into the void and die? Because honestly, that would be hilarious.
-
3
-
-
But in TF2, snipers have SMGs. Saturday Morning Gaming. Three words. Half Life 3 confirmed.
-
3
-
-
For clarification, if it's not obvious, newnerd is the primary server—the naming being a relic from when we migrated servers ~3 years ago—and creeper is our secondary box.
-
I was looking over your list, and one thing stuck out: I think team balance is a terrible idea.You spend hours furthering the progress of one team, putting in time and effort toward the objective and gearing yourself up. Then suddenly, you're on another team, isolated from the people you were playing with...and now you can't access all of the gear you had. You're back to square one.Couple that with the intense competitiveness (you fight one team for a long time and suddenly end up on it) of the game and you'll have no end of discontent. Outrage of being switched to another team, possibly the team being dicks since you were "the enemy."Auto balance is just an all around bad idea. It sucks in a short FPS game, and it's entirely ridiculous in a game where with a persistant, alterable world. Any work you do is virtually obliterated. It's not really conducive to encouraging donations...Additionally, there's just not a good way to *do* it in a game where people can log out and log in at will. If you balance off online players, that would obviously not work. And if you balance by total offline players, it would be evenly balanced already based on the plugin's normal attempt at distributing them. You'd have to log "last seen" times and use some silly algorithm to determine when a team is "unfairly disadvantaged," and then it all falls apart with differing time zones and such. Then there's the balancing itself. How do you decide who gets moved? Points scored? Randomly moving players over? Shuffling the teams in their entirety? It's an incredibly complex feature that's bound to create unfairness.Resets are the same. If I hadn't been sick and barely playing anyway, I would have rage quit after the reset that happened. There's no way in hell I'm going to spend six hours mining and building only to go to bed and have it gone in the morning. No way.One team is always going to win: the only thing to be done is to ensure that the map is designed in a way that gives both teams a fighting chance, and a chance to bounce back. It's happened in the past with no issues. (The biggest problem this past CTF was the lack of outer walls, which was primarily due to time constraints from building being put off.)A much more equitable solution would be allowing players to switch to another team by choice, if the team has fewer players, and only allow them one switch to prevent it from being abused.
-
2
-
-
> p.nerd.nu player for six years
PvE rev 1 started in January of 2011...
We've got a time traveller here!
-
2
-
-
It's also worth checking MC Bouncer and forum activity, as another major moderator duty is moderating chat. Sometimes modreqs will be sparse, as Sir Didy mentioned, but they may still be doing things like issuing warnings for chat conduct or contributing in other ways.
-
1
-
-
The server is now up and open to everyone.
-
1
-
-
It really is too bad that we couldn't stream CTF without people being able to spy on the other team, because that would have been great.
-
In my mind, as long as they've given a heads up, they can just hold in stasis until they return (as long as their fellows can hold up the fort while they're out, of course).
I think that's the biggest thing everyone wants to see here, basically. That, and not having any changes made without the agreement of the server admins. I'll agree that a harder policy is needed for the moderator group (we do have a lot of basically inactive mods who just pop in to remain "active") though any system can be exploited in such a manner. I think we can get away with a more flexible system for admins, though.
Inactive techs typically aren't able to help as much in picking out new candidates for tech since they aren't really engaged with the community enough to know who is trustworthy and knowledgeable enough for the job.While it's true that they can't make a blind assessment of trustworthiness or capability, they can still be involved in the interview process. We don't let anyone in until they've passed a technical interview to assess skills directly. (Deaygo and LadyCailin asked me a pile of technical questions and had me explain the workings of a messy bash script Cailin had stripped the comments from, for example.) Nobody gets in without proving they're capable, even if there's a lot of "on the job learning." Cailin has expressed interest in remaining involved with the interview process, even though she's in the aforementioned state of "stepped down, but still hangs around anyway."
-
1
-
-
So...I think the server is more or less ready to ship on schedule. We've hit the point where we just need to prepare to throw the switch and hope all goes well. I still have a moderation guidelines proposal I'm drafting, along with a rundown of commands, but other than that we're nearly ready. (I have a couple more things to add and work on, but they can wait until after launch.) \o/
So the next step: getting you admins all on the permission system before we go live. Whichever of you who have CS:GO and want in-game permissions, send me a PM with:
1. Your SteamID (http://steamidfinder.com)
2. The email address you want associated with your Sourcebans account
I'll create an account for you on Sourcebans and you'll have permissions in-game to ban, kick, send broadcasts, etc..
I'd like to get all the CS:GO-playing admins set up before launch, so there's a reasonable pool of people who can hop on and intervene if something needs to be moderated. From there, we can work on opening it up to the moderators as we smooth things out from the policy side. (This is a whole different animal from Minecraft, and figuring out how to treat it from a moderation standpoint will be a learning process.)
For Barlimore and/or Mrloud: if you'd like to talk launch date, maybe collaborate on the aforementioned moderation document and public announcement, give me a shout on IRC.
-
The replication issue is a big one. While there are some things that we can figure out based on prior knowledge or a little bit of research ("oh yeah, that's probably caused by x"), the more obscure issues are problematic: if we can't reproduce what appears to be a crazy random glitch, we can't fix it. (And less information = a lower chance of being able to reproduce it.)
For example: the "items despawn too fast" modreq. I've tried several times to see if I can spot an item despawning before the limit, but as far as I can tell, it always despawns right at the 6000 tick mark (5 minutes at 20tps, slightly longer if the server isn't keeping up a steady 20tps). If something like that can't be replicated, it can't really be fixed, since there's not a way to ascertain the issue...which means it pretty much has to be chalked up to "Minecraft is derpy and you got screwed. Better luck next time. ¯\_(ツ)_/¯"
-
However we were all added to our roles for a set of key responsibilities, for the Tech Admins, those tasks seem to be across your trello page(s) and that is what is expected of you for the most part.
That's...not really the case. The majority of things aren't on Trello. They're quick things done on on a more ad hoc basis, upgrades and restructuring that are important to ensuring things run smoothly (but don't constitute new and shiny things or fixes to issues submitted), discussion of such things, etc.. Trello is mostly "things someone asked for" and not "things that ensure everything continues to run smoothly." (Nobody's going to make a Trello item for something they intend to do themselves over the next hour or ten minutes or whatever.)
The best people to judge inactivity is the teams themselves. Nobody's going to know better. If group X has concerns about the activity of member Y and desires outside involvement, then they should ask the heads. If they're all decidedly AWOL with no means of contact, then emergency intervention may be necessary. To use padmins as an example again, if they had inactivity problems, they should communicate that with the heads. That's all. No arbitrary time limits, no half-baked attempts to apply metrics to activity. The team in question will know if someone's fallen off the face of the earth, or if they're out for a reason, or whatever.
For moderators, the same way we've always done it works: just do a quarterly cleanup of the obviously inactive. It's far less work for everyone, conveniently in batches, and doesn't result in prematurely removing permissions only to have to re-add them two weeks later.
This policy is not aimed at "other" admin teams, it is aimed at all staff, head admins and all. It would be hypocritical for us to not consider ourselves with this policy and a foolish mistake to ignore the issue of comfortable inactivity.I'm not saying it was. Just that the head admin activity issue needs to be fixed far more pressingly. Everyone else manages to move their inactive team members out and select new ones on a timely basis. (Except perhaps Survival these days. I have no idea what's going on with that mess. Apparently C45Y is running Survival now?) Yet we keep running into the problem of only one head admin being active for a long stretch. This is more or less a non-issue for everyone else.
My Proposal (Admins)
- Issues of staffing should be more or less left to the individual admin teams. They have the final say on who gets added or removed, but heads have veto rights on someone being made an admin. It's all on them to decide whether someone is being acceptably inactive or not. If an admin falls off the face of the earth or doesn't do anything at all for a month and a half without making it known that they'll be absent, they should make the problem known to the heads, who can officially reach out and figure out the inactive admin's intent. (A fully staffed server should be able to handle one admin taking an extended leave, and one more being less than active for a shorter period. That's why you have four of them.) It should be fully up to the server's admins, unless there are circumstances that dictate intervention.
- If a whole admin team more or less disappears (*cough* Survival *cough*) then the heads should take emergency action and intervene. This would be one such case of "extenuating circumstances."
- No arbitrary time periods. Each server has different activity requirements, depending on where they are in the rev cycle. As long as things are getting done and nobody's getting the work dumped on them exclusively, we're good.
- Additionally, I have no problem with there being "inactive techs." They're a rare and important resource, and I'd rather keep someone like smiler100 or LadyCailin around, even if they aren't "active." They may resume being active, and even if not, they have knowledge of the workings of things, and we may have things to ask them. (We keep LadyCailin and muldoonaz around in the tech channel exactly for that reason, even though they officially stepped down and no longer has access to things. That, and because drunk Cailin is amusing. :P) If they want to step back their activity indefinitely and come back when it suits them, I have zero problem with them remaining "on staff" for that time.
My Proposal (Moderators)
- Quarterly cleanup of obviously inactive moderators. Do a sweep and reach out to the ones who are barely around and ask their intent, and flat out remove the ones who haven't logged in at all in that quarter. Modreq and forum activity should be considered as well, though not to the point of ignoring non-request-based moderation. (Half of moderating is, well, moderating discussion. Not just flowing water.) But in saying that, time spent in-game vs. time spent moderating should be considered in cases like gabe/minotaur/geb/whateverhisnameisnow, with excessive time in game and a small percentage of reqs completed.
- Once a list is compiled of who to remove, pass it on to the techs so it can be done in one batch.
- A planned inactivity thread where moderators can post "yeah, I have finals for the next month" or whatever as insurance against being removed in one of those batches, and so we have some idea of why they're inactive for more than a few weeks.
-
1
-
Staff who significantly drop their activity levels below those of their counterparts over the course of a three week period will be deemed inactive; these will be moved to the inactive section on our website and notified of this change. Admins, due to their responsibilities toward greater involvement with the community, have a threshold of two weeks. Exceptions can be made for people who inform us of planned inactivity.
That is incredibly short and, I must say, a terrible idea. By that standard, we'd have to remove most of the heads, padmins and the sole remaining sadmin. Hell, I was sick for three weeks that I certainly didn't plan on. Never mind that this is all a volunteer position, and having such high expectations is kind of absurd...especially given that the definition of activity is vague, and pretty hard to pin down at an admin level.
Can you, as a head admin, honestly judge the activity of...say...the padmins? The rev is fairly stale, and most of what they'll be doing is planning and dev stuff, which is all done behind your back. In their own IRC channel, private channels, who knows. They're fulfilling their duties, but it's not like they're hanging out in game and waiting for modreqs or whatever. Does that count as "active?" Most of them pop in and out of IRC and don't leave a client idling or use a bouncer. Are they inactive? I'd argue that reachability by other staff is a key point of activity.
How about techs? I guarantee that nobody outside of the tech team has a clue what goes on behind the scenes. You get a glimpse now and then, but only at the surface. We've got our own channel where we discuss things, and there's always something in development or maintenance of some sort to be done. But all that everyone else sees is superficial stuff, when someone needs permissions adjusted or some issue is raised on the Trello boards. And especially at that level, I don't want to be mucking around with revoking permissions over a minor absence. If c45y or Dumbo or whoever wants to take a break for a month, pulling their SSH key and crap would just be a bureaucratic waste.
And...well. How about those head admins? It's certainly hard to get a hold of them at times, and they have chronic activity problems. It's a bit hypocritical to talk about activity levels when the heads, of all the admin groups, have the worst reputation in that regard. It's possible it's exaggerated by the same issue as the techs (back-room activity being more important than what everyone sees), but reachability has been a huge problem in the past.
At a moderator level, I'd definitely rather have a surplus of moderators that have unknown activity and could come and go on their own instead of removing permissions on a very tight deadline. That will only create a shortage, when our less active ones might tire of Minecraft and not play for a few weeks, then come back on the fourth week. No sense in having to adjust permissions everywhere over and over again.
This is draconian and impractical. I hope I don't come off too strong here, but I think this will cause some serious problems, which will lead to a further shortage of moderators and create more issues at an admin level.
-
1
-
-
I think it's fucking stupid, and would never support such a change. It's unnecessary censorship and moral policing that I, and many, many others want no part of. I absolutely have no problem with swearing, nor would I under any circumstance agree with the assertion that it's a problem.
Besides, we cater to a primarily older audience (which is a rarity that sets us aside from other public servers) and:
1. 10+ year olds swear plenty
2. we really don't want to be babysitting more then we already do.
-
1
-
PvE lag topic
in Problems & Issues
Posted
CobraCorral appears to exclusively use entities uniqueIds behind the scenes, so I'd assume it would pick things up properly when re-enabled, if it were temporarily taken out.