[Rev 27 Is Coming!]

1 hour ago, Shnozzles said:

As long as people aren't stacking portals on top of each other and rules are set to prevent griefing, what exactly is the harm? I'm all for letting smaller builds/towns have a chance at portals too. There's really no need to guard them so jealously. 

As long as the stacked portals are made by the same player or town, then even the stacked portal problem is a non-issue. If I remember correctly, lots of portals right next to each other is the basis for at least one, if not many, useful farms when one is playing vanilla minecraft. To ensure that these portals are, in fact, placed by the same player or town, you simply do as you said in your edit:

1 hour ago, Shnozzles said:

Edit: Maybe make it so that portals have to be modreq'd inside established claims? I think that's a fair compromise that would cut down on portal spam.

except you make sure that the claim is big enough to prevent portals from becoming too crowded. The exact distance required is partially subjective, but at a minimum should be enough blocks to allow convenient access in the nether (including by horse!), and a minimum of an 8-block radius from the portal in the overworld (plus the same convenient access as would happen in the nether, though 8 blocks might be plenty for that purpose, and if not, likely comes close, unless you add an excessive amount of decoration around the portal).

[Rev 27 Is Coming!]

I don't see why there is so much opposition to the anyone-can-make-a-portal idea, given that the linking distance can be reduced. If we set the linking distance to 0, then there would be no interference between nearby portals, except in the case of overworld portals that are within 7 or 8 blocks of each other (depends how you count: one block in the nether = 8 blocks in the overworld (horizontally, that is-- vertically the ratio is 1:1 unless you are too close to, within, or above the nether roof), but some people might decide to only count the gap (7 blocks), as opposed to counting one of those portals in their measurement (8 blocks)). Any two portals which are that close to each other are most likely so close as to make the one you come out of irrelevant. To turn that "most likely" into an "always", all that needs to be done is for the owner of the requested portal(s) to have claimed at least an 8-block radius around said portals.

And speaking of claims, one rule that should (for practical purposes, its more of a "must") be implemented in order to prevent portals from griefing other builds is that the owner of the requested portals must claim the area/volume that will contain the portal(s) both in the nether and in the overworld.

[Revision 25 late rev feedback:]

Spawn

-I largely agree with what the others have said: the exit to the spawn building being right on the main intersection was great. On the other hand, the custom traders were hard to find because they were scattered and hidden in all sorts of nooks and crannies. Next time, lets put all the custom traders in one building.

 

The Nether

-I am not a fan of the custom mobs.

-If the nether is all it is hyped up to be in 1.16.X, as is that new ore/block, netherite, then I think that aside from maybe plumping ores and such (likely including netherite), the nether should be either vanilla, or close to it, next rev.

The End and Elytra

-Perhaps instead of obtaining an elytra by a non-vanilla dragon fight, we simply have the following setup: We retain the multiple-islands structure of the end, but while some of the outer end islands can contain ores and stuff like they have for a few revs, others can regenerate under a different seed every so often, so that there will always be new end cities and thus, new places to find elytra the vanilla way, no matter how late into the revision we get.

Custom Drops and Custom Trades

-The custom drops seemed to drop at reasonable rates.

-The 1:1 ratio of custom drops to nerdcoins (or other custom units of currency) worked well. If there are custom drops and custom trades, next rev, please definitely keep this system.

Rev Theme

-Events and server planning were tied to the theme by just the right amount, this rev.

Map Size and Portals

-The overworld was a decent size, this rev, though I wouldnt mind a somewhat bigger map, as long as the bigger map comes with nether portals spaced similarly to the current rev (in a grid spaced 250ish blocks apart in the north-south and east-west directions (in the nether, that is, which corresponds to 2000ish blocks apart in said directions in the overworld), but not 250ish blocks in any diagonal direction (roads are easier to follow when things are kept in a rectangular grid, rather than in concentric circles)). In line with this, if we go to a significantly bigger map, there should also be more portals, rather than the same number of portals spaced further apart. As I said at the beginning of this section, though, the map is a decent size, as is, so if we dont increase its size, I am perfectly fine with it. On the other hand, the map might be able to use a slight downsizing, but I don’t think it should a whole lot smaller, unless you plan on expanding it later in the rev.

-I don’t see why there has to be a lot more space in the nether than the corresponding distances in the overworld (a 3000 x 3000 block nether would correspond to a 24000 x 24000 block overworld map), though I can see a benefit to having some extra space on the nether side, so that people can build grinders/platforms in areas where they are more-or-less guaranteed not to cross paths with road and rail networks (not that doing so is always a bad thing).

 

[Revision 24 late rev feedback]

Map size and Rev length: Instead of a 7k x 7k map from the beginning, maybe we can try starting with a very small map size, such as 2k x 2k, and every 1 to 8 weeks (or perhaps whenever it is determined that the current map is or will soon become too crowded, or there is a desire for more of one or more biomes that are currently in short supply) we expand the map by 2k in each of the two horizontal directions. The map continues expanding until a new version of Minecraft gets released (and we determine that we are able to update to it), or perhaps until travel across the map is deemed impractical (which we would have to define as some amount of time that is required to travel that distance), or until the map file is deemed too big.

Spawn: A simple spawn that is easy to navigate and treats all directions of travel at least roughly equally would be best. Perhaps players can walk through the list of rules and information, then take a water drop/elevator down to a central area with roads coming out of it in similar fashion to rev 22. The spawn nether portal could be down a set of stairs directly below this central area. I am also not opposed to a hotel-style spawn (similar to rev 20), provided it is still easy to navigate and treats all directions at least roughly equally.

Nether portals: How about we stop making nether portals something that only a few people/cities get their hands on, and start allowing anybody to place a nether portal. If you are worried about grief, could we not just make an unlit nether portal somewhere, and then modreq to have it lit (surely we can trust the mods/admins, or perhaps LogBlock, to determine if the nether portal will cause grief in the other dimension (remember: distances in the nether and the overworld correlate via a simple ratio, and whether or not two portals in one dimension lead to the same portal in the other dimension is determined by how closely they are spaced, and should be predictable in advance via calculation (and perhaps observation, with mod/admin assistance if need be)).

Terrain generation: I am not certain whether or not non-vanilla terrain gen is beneficial in the overworld, but if we decide it is, lets at least make it so that biomes match with the stuff inside them. For example, if F3 tells me that I am in a plains biome, then I should not see an overabundance of naturally-generated trees. If F3 tells me that I am in a (regular) forest biome, then I should not expect to see jungle trees (unless I am in a transition zone between a jungle biome and a regular forest biome). On the other hand, if we determine that a whole biome is necessary to make more abundant, then we can change a biome (or a portion of a biome, in the case of something like an ocean biome), and make sure that it shows up as that new biome in F3, and also has only the features that could have been in that biome had it been naturally generated.

Events: My favorite event, so far, was Super Mini Games. I think the time for the events are good, though I am not opposed to them being an hour earlier. What I hope does not happen, is that they start later than when they start, now.

[MiniGames & You! A discussion...]

On 2/26/2019 at 12:16 AM, Sapphric said:

I think we should make it an archive server. Set it up with multiworlds that host previous P and C revs in creative mode (edits clear on disconnect). Rose already does this with their server, but it'd be nice to have it in house.

I agree with this, but

On 2/26/2019 at 1:16 PM, bermudalocket said:

Here are my quick 2 cents:

1. The minigames server currently has 2 gb of memory allocated. About a week ago I took the server offline entirely in order to (hopefully) give a boost to the lobby, which has been having some issues lately. I have not noticed a major difference. Also, keep in mind that despite (for example) PvE having 6 gb of allocated memory, on average we're only using ~14% of that even at peak times. Memory is not the bottleneck many people seem to think it is. The largest memory spikes occur when the server restarts and when new chunks are generated.

 

On 3/20/2019 at 6:40 AM, totemo said:

I'd be supportive of us adding one or possibly both of the following servers:

1. Vanilla snapshot, survival mode. I was originally thinking creative mode for this, but i think it would be less hassle to support survival and add a little datapack for shulkers of rare items, with limits on those to avert a lava/TNT apocalypse. I can name at least 8 players who have played on private snapshot servers. It makes sense that we bring those people back into the fold and host them ourselves. Some of them, at least, paid for our current hardware. Mojang's current snapshots are quite flaky, and as such, we should offer no guarantees of stability or continuity of the snapshot world. The expectation should be that the world will reset once a week, if necessary, and no download will be offered. I don't think that any concerns about "stealing players" from PvE, such as those expressed here are valid because chaos is a different beast (e.g. no protections), and because they're still our players, and we serve them, not the other way around. But, explicitly managing expectations around stability and world continuity go towards allaying some fears of an exodus from PvE. Judging by the daily discussions on PvE regarding new 1.14 mechanics, I would say there is a demand for this kind of server from time to time, with spikes in activity every time Mojang releases a new snapshot.
2. I would like to try a UHC server. It may fall by the wayside like minigames, because it's somewhat the same idea. That depends on our player base. They will decide its ultimate fate. The top Google result for "minecraft 1.13 UHC plugin" is UHC-Core, which has apparently been around forever and appears to be a turnkey solution for 1.13. I'm generally opposed to writing our own plugin for anything that already exists, unless it fails some critical requirement. Non-techs also generally have no idea how much effort it is to make things run smoothly. It's always best when someone else does that.

I say two servers. We have the RAM. We have 8 virtual cores, taken up by PvE, C, 3x PvE carto processes (because the 1.13 carto software is a dog), and 1x C carto, for a notional load of about 6 cores. The PvE carto threads are "nice"d, meaning that if there is something more important to do (like running a Minecraft server) in a particular moment, then that thing takes precedence over the carto. So in principle, we can run those two virtual cores at full tilt without impacting PvE or C. The carto might slow up a little, but I expect that the snapshot and UHC servers (if we get them) would not be occupied 24/7, unlike PvE. I think we have to give up on the idea of updating cartos very frequently in any case. We currently can't update P's carto more than once a week. Actually playing the game is obviously more important than looking at pictures of someone else's builds. Once C updates to 1.13, I expect that carto will take even longer than PvE (because the map is massive).

I also think that a snapshot server would be useful, although I am hesitant to say that it should alternate with other things. I would not like to see the snapshot server, while acting as a snapshot server, be in complete chaos mode, as I think some valuable things can be learned by having it in creative and giving players the option to /(game)mode into and out of survival, because it allows people to explore new mechanics easier, such as determining the best new-version villager breeder and villager market layouts. Since we have two-or-more cores, then I don't see why we could not do both an archive server and a snapshot server.

Also, if somebody discovers a reasonable way, then having the archive server such that a 1.13 client could connect to each world, but each world would, in fact, be running the version of Minecraft that it ran on back in the day, then that would be a nice bonus.