Jump to content

wyguy2014

Members
  • Content Count

    2
  • Joined

  • Last visited

Posts posted by wyguy2014


  1. 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.

    • Upvote 1

  2. 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.

    • Like 1
×
×
  • Create New...