Home of The Tech Fortress Servers

Sunday, April 8, 2018

No More Spawn Posts

Happy Easter! Today's Divine Mercy Sunday (or at least at the time of this post!)

A significant change is taking place on Tech Fortress - and no, 1.13 still isn't out yet. (Though to be honest, I quite like the slower update cadence.)

The first of these is the removal of spawn posts.

In short, everybody (without having a bed spawn) will spawn at the global world spawn point.

The decision to drop spawn posts was made to favor the global server community over the ease of traveling to uninhabited lands. That, and the fact that a global spawn point is in fact a vanilla multiplayer functionality. Spawn posts make more sense if Tech Fortress were to emulate a vanilla singleplayer experience. But what would be the point of a multiplayer server if all it were intended to be is just singleplayer with a chatbox?

Spawn posts

Spawn posts were implemented a couple years ago to deal with the issue of new players having to travel far and great lengths in search of fresh resources to get started. This is probably the most significant contrast between a vanilla singleplayer game vs. a vanilla multiplayer game; the older a multiplayer world becomes, the further new players must go to visit new and unexplored terrain, which is often the source of fresh resources to get started.

Tech Fortress' history of solving this problem has changed many times. When Tech Fortress was publicly released, new players would be randomly teleported to a location, so they can get started right away. Subsequent respawns would occur at the world's main spawn point, so the player would always have a consistent path to return to their settlement in case their bed spawn failed. The primary issue with this solution was that the plugin employed did not always work, nor did players generally survive to make a bed before they died. This also was a very singleplayer-focused solution - friends who would join the server would be separated several hundreds or thousands of blocks apart.

As such, a new solution was put in place. Roughly a few months later, the random teleportation plugin was removed, and the "water transportation" system was built, allowing players to traverse roughly 600 blocks in the cardinal direction of their choosing via a boat in a river-like tunnel, with speeds comparable to traveling via minecart. However, this system was broken when the 1.9 boats arrived. The remains of this system can still be seen today, although it is now permanently closed due to the aforementioned boat changes.

Shortly before the 1.9 changes arrived, spawn posts were implemented. Instead of a global, unchanging spawn point, players would spawn at a spawn post. The posts were very minimal, and automatically generated with signs. As new players claimed near a spawn post and consumed resources such as trees, ores, and unclaimed areas, a new spawn post would be designated as the place where new players spawned at. This provided a solution such that players have access to fresh resources, while any friends that also join spawn next to them.

So why was this scrapped? In nearly all survival servers, there are two types of players - those who stay long-term for years, and those who effectively quit after a few months.

In nearly all cases, new players who join will encounter the long-term players in chat. If they wish to meet these long-term players, they will often be far away from them, due to the nature of spawn posts always attempting to spawn players next to fresh resources and in uninhabited areas; these places are generally away from where long-term players live. Therefore, having spawn posts is in fact worse than having a global, unchanging spawn point, if one wishes to meet the existing community of players!

Thus, the decision to drop spawn posts was made to favor the global server community over the ease of traveling to uninhabited lands. That, and the fact that a global spawn point is in fact a vanilla multiplayer functionality. Spawn posts make more sense if Tech Fortress were to emulate a vanilla singleplayer experience. But what would be the point of a multiplayer server if all it were intended to be is just singleplayer with a chatbox?

Monday, January 15, 2018

IP change!

So I'm not sure what happened to the old domain, but please change your IP for all servers (Team Fortress 2 servers should remain unaffected since the IP address is saved instead of the domain).

Tech Fortress: tf.robomwm.com
MLG Fortress: mlg.robomwm.com

Team Fortress 2:
MvM Fortress: tf.robomwm.com:27015

Update: the old domain apparently has been re-instated just as silently as it died. Either way, I have a new domain now and going to use that from now on.

Sunday, June 11, 2017

1.12 is here!


Mk, this wasn't too bad of an update. Thanks to RexTempus and yellowjacket6 for helping test a couple things.

Tech Fortress is now on version 1.12.

Additionally, a new spawn post has opened, named St. Gregory in honor of St. Gregory the Great, one of the first doctors of the Church. You can read about him or watch:

Monday, April 10, 2017

MLG Fortress: April Updates

I was going to hold off until after I made some other updates this month, but there's been quite a bit of confusion on the new health canister system.

Major stuff

  • Health canisters:
    • Drop more often
    • Max health limit of 37 hearts (from 90)
    • Any additional health gained by consuming canisters will be lost on respawning

Minor changes

  • Improved knockback resistance with mobs. Mobs will no longer "freeze" when being hit.
Monday, March 20, 2017

MLG Fortress: March Madness


ayyy m80s dis da first official post 4 MLG Fortress! Adding new things to the server is kind of useless if nobody knows about the changes; thus, updates to MLG Fortress will be posted here regularly.

Big updates

  • The /memebox
    • The /memebox now powers all the memetastic music you hear on the server. Simply click the link it gives you, and leave the memebox webpage open while you play. No more 40MB resource packs!
    • This will support multi-track music discs.
    • Some areas the /memebox is used:
    • At the mall
    • When you're fighting multiple mobs
    • More to come! (Killing spree, etc.)
  • Clan friendly fire
    • Clan friendly fire is automatically disabled in survival worlds.
    • Projectiles will pass through allies.
    • Clan friendly fire is enabled everywhere else (for minigames, pvp, etc.)
Minor changes
  • Low health ambiance: Changed "gasp", added breathing (hmm, the possibilities we could use this for, and it's a vanilla sound!)
  • Explosion damage and kills caused by weapons are now counted.
  • Transporter sounds before and after teleport.
  • New damage sounds:
    • Fall damage is distinct (did you just crack some bones?)
    • A different noise plays if you took over 10 hearts of damage
    • Other players make a different noise when they're damaged (easier to distinguish when you're hurt vs. others getting hurt).
  • Periodic reminder to open the /memebox (everybody seems to forget to do this, but for right now it is better than the 40MB alternative...).
  • /warp uses the /tpa system.

Other new things are coming up, particularly minigames, as they are slowly being merged into MLG Fortress.

See you soon!

Sunday, December 25, 2016

Merry Christmas!

Merry Christmas! Hope you have a happy and holy Christmas celebration!
Wednesday, September 7, 2016

Understanding and Mitigating Network Connection Lag

Lately there's been reports related to network lag. While this is naturally due to the player's internet connection, I've lately discovered that there are ways to alleviate this type of lag.

Since this is the first of potentially many more posts on lag, it would probably be best to quickly outline the common types of lag. (Yes, there is more than one type of "lag.") Using a diagram is probably the easiest way to depict this:

As depicted above, server lag (which you can monitor via /lag) is only one of many "types of lag;" other  areas that can lag include the server's connection to the internet, the "internet" itself, the player's connection to the internet, and the player's computer. The player is often referred to as the "client."

To better illustrate this concept, let's use the example of a cow moving towards water. First, the server  calculates the instruction of where the cow goes (server hardware). This is then sent out to the player (internet connection). Finally, the player's computer receives the server's instructions for the cow, and makes the cow move on the screen.

If the player's connection was laggy, the player won't know the cow has moved because his computer hasn't yet received the instructions. This doesn't mean the server is lagging (as the instructions have been made and were sent), but rather the player's computer hasn't received the instructions yet.

Now that we have discussed connection lag, you may be wondering if there's any way to fix this issue, other than getting a better internet connection. And the answer is yes, there are ways to help reduce the problem!

Remember our example with the cow? Well, now let's assume there's 1000 cows. That's 1000 sets of instructions being sent to the client about where each cow is going. As you can imagine, more connection bandwidth is being used to send 1000 instructions all at once. Therefore, we can conclude that as more cows are near a player, the player uses more of the connection to receive instructions about each cows' movement. Even though the server may be able to handle generating instructions for a 1000 cows, your connection may not have enough bandwidth to handle all those instructions for each cow; I experienced this personally, seeing my ping drop and more of my connection bandwidth used when I visited a player's cow farm.

Thus, you can probably determine that being around less animals and monsters (such as cows) will help reduce connection lag issues. Designing efficient farms that don't hold a ton of animals/monsters at one time (such as a mob grinder that quickly kills mobs) or building a dock for boats instead of leaving a bunch lying around would make things a lot easier for your connection to handle, for instance. Efficient redstone designs that use less gates or devices (repeaters, comparators, etc.) would also help, since the server sends you the state of each and every device's state (as well as making your redstone contraptions operate far faster!)

Hopefully this post has given you a good overview on "network lag," and some ideas on how to make it less of an issue while playing on Tech Fortress, or any other server for that matter. Leave a comment if you have any ideas of your own that you'd like to share, or if you have a question on anything discussed here. Hope you have a less laggier day!