Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - VoiDeD

Pages: [1] 2 3 ... 6
1
General Discussion / Official Discord!
« on: June 08, 2020, 11:14:04 pm »
Come one, come all, to the official Saxton Hell discord server. Over 10 years in the making.


2
General Discussion / New donator perk: Taunt menu
« on: December 18, 2015, 06:05:59 pm »
I've added a taunt menu plugin for donators to use any taunt they like. You can activate it with the !taunt command in chat.

3
General Discussion / MOVED: Admin Abuse
« on: October 18, 2015, 04:43:52 pm »

4
Zombie Hell / Balance Changelog & Discussion
« on: May 08, 2015, 04:34:58 pm »
Previously, we've held the belief that the nature of ZF's perks are inherently difficult to balance, as some players will always believe that a given perk is either over powered or under powered, and thus the perks have been (mostly) static for many months. It's becoming increasingly clear, however, that some perks are fundamentally flawed (wise, friend, etc) and need tweaks.

Thus, this thread will be used as the official ZF perk balance changelog and discussion.

5
Off Topic / MOVED: ZF eviction notice donator glitch?
« on: May 01, 2015, 12:48:14 pm »

6
General Discussion / Admin Applications Reopened!
« on: March 21, 2015, 02:27:22 pm »
Our admin application form is now reopen for anyone looking to apply to become an admin here at Saxton Hell.

As always, you'll need some free time to fill out the considerably lengthy application form. You'll find it here.

We'll be reviewing responses to the form and if we feel you're a good enough candidate for being an admin, we'll get in touch with you. What can explicitly disqualify you from becoming an admin? Only one thing: asking about your submitted application.

If you've previously applied, you can apply once again for another chance.

7
Machine Hell #1 & #2 / It's Back!
« on: November 13, 2014, 02:54:12 pm »
So MvM hell has made its return to the Saxton Hell community!

However, for now this server is going to be a trial run and there is no guarantee just yet that it's going to stick around. This is mainly due to the huge performance requirements MvM had back when we ran it before; I want to make sure that the MvM server isn't using up too much of our server resources. If everything turns out to be normal then the server will remain running. If not, we'll have to invest in purchasing a separate server box to host MvM and any additional servers we want to run.

Additionally, the intent is to run this server with the same configuration we had before: 10vm, mvm stats, lots of custom maps and missions.

Right now we're just running the stock MvM missions and maps, so if you have any suggestions for things you'd like to see: please post in the suggestion thread!

8
Machine Hell #1 & #2 / Map & Mission Rotation / Suggestions
« on: November 13, 2014, 02:49:25 pm »
This thread will be used to keep track of the maps and missions that are added and removed from the mvm server rotation.

Feel free to discuss any map suggestions in this thread!

Here's our current map rotation:


9
Saxton Hell / VSH & FF2 - Keep halloween spells?
« on: November 12, 2014, 05:06:32 pm »
So now that Halloween is coming to an end, the subject of spells in VSH and FF2 is something I'd like some input from everybody on.

Should we keep spells enabled? They introduced some interesting gameplay mechanics that perhaps everyone wants to keep playing with.

10
Zombie Hell / Reworked Team Prefs / Selection
« on: November 06, 2014, 05:29:49 pm »
So after reviewing the original ZF code for team selection, I've decided to completely rework how team prefs and team selection works in ZF. It used to be considerably busted and would leave players on the same team round after round in certain cases. So I've redesigned that entire bit of code.

Team selection works a little like this now:

1. All players will get placed into one of three buckets based on their team pref (if any): survivor, zombie, and none. Players without a pref are assigned the "none" bucket.

2. Team selection will alternate between picking one survivor and one zombie at a time. It will continue picking survivors and zombies until the survivor ratio is met, and the rest of the picks will be dedicated to zombies.

When selecting a survivor, there is first a random roll done to decide if a player should be chosen from the survivor bucket. The odds here are approximately 3 to 4 that someone with the survivor pref will get picked for the survivor team. This means that preferences aren't guaranteed, but instead just highly likely.

If the roll passes, a player from the survivor bucket is randomly chosen to be a survivor. If it doesn't pass, a player from the "none" bucket is chosen instead. If there are no players available from the survivor or none buckets (if all players have pref set to zombie, for example) then a random player must be chosen from the zombie bucket.

The same logic is then repeated for a single zombie selection (choosing from the zombie bucket instead of survivor, however).

Then the logic will repeat the survivor and zombie selection until enough survivors have been selected to fill the survivor ratio (currently 60%).

These changes should hopefully prevent players from getting stuck on the same team every round as it's considerably more random than what the ZF plugin had before.

If you still seem to find yourself getting stuck on the same team over and over, let me know as I may have introduced a bug in this implementation, and I'll be able to check against the team stats collection I introduced as well.

11
General Discussion / Server Relocation (Fully completed!)
« on: September 22, 2014, 12:20:13 am »
Just wanted to take some time to write out an announcement about some of our future plans regarding the servers and to allow you guys to provide some input on this.

Our current plans for the somewhat foreseeable future are to relocate our servers to a new hosting provider.

The primary reason for this decision: I'm frankly getting annoyed by the poor condition of our current host's networking situation. We've been with our current host for perhaps 3-4 years (this predates the formation of this TF2 community as well) and, for the most part, we've been satisfied with what we were paying for. As of late, however, it's become clear that our current host simply doesn't have the capacity to withstand the occasional DDoS attack and their network (and the networks they peer with) has become detrimental and less ideal to hosting game servers like ours.

So, here's the upside:

1. We're going to be buying brand new beefy hardware. This should translate into more server capacity, and we can think about expanding our servers to run more gamemodes (surf, slender, etc) in the future. It's hard to tell just how many more servers we'll be able to run just yet, but once we're situated at our new host we'll be able to see.
2. We're going to be on a better network that should alleviate some of the complaints we all share about random ping (300+) spikes that last hours on end for only certain groups of players.

And here's the downside:

Our server is currently located in Dallas, Texas which places it roughly in the center of the United States networking-wise. Our new server is going to be located near Montreal, Canada; namely in Beauharnois. This means that, due to the laws of physics and the wonderful limit to the speed of light, some players located on the west coast will inevitably have a higher ping to the new location.

It (hopefully) won't be too bad for the majority of our players, and after some spot checking with a few people located in California they reported only getting 30ms over what they currently get. One reason for this is due to our new host's US network. If you live near one of the cities marked as a "Point of Presence" you should generally get favorable latency. If not, your latency may be higher.

If you're curious about how your ping will be (and I know I definitely am), please use this speedtest site and post what kind of ping you're getting compared to what you currently get when on our servers right now and the general location where you live.

The time frame for all of this is roughly during the second week of October, as that's the time of our current billing cycle and we'll want to ensure we have a full month to evaluate the move and not have to pay for more months of extra hosting than we need to. Since we'll inherently be paying for another server during the move, that time would be ideal if anyone is looking to donate and support us.

Additionally, another thing that will inherently be changing is that our servers will be getting new IP addresses. If you have our servers favorited, this should hopefully be painless as Steam should automatically update your favorites to include our new IPs.

13
General Discussion / Loading Music Suggestions!
« on: August 16, 2014, 07:27:29 pm »
I figure since there's a saysounds suggestion thread there might as well be a loading music suggestion thread.

If you're not sure what loading music is: it's a feature (that you can enable with the !loadingmusic command) that will play random music while you're loading into the server during a map change. Everyone who has the feature enabled will hear the same song during a map change.

You can check out what existing music is available here.

So feel free to use this thread to suggest what music should be added!

14
General Discussion / MOVED: Map Time Reduction
« on: August 04, 2014, 09:04:46 pm »

15
This is a pretty common complaint I hear on the DB server all the time.

The response is simply this: Actually, your client sucks. You fix it.

Enable your net_graph (or perhaps you already play with it enabled).


See that lerp value? If that value is anywhere below 30ms you are going to experience "rocket skipping" and other kinds of jittery lag.

Here's the problem: lots of dodgeball players like to believe they're experts in all things Source Engine Configuration, and share configs that set the cl_interp and cl_interp_ratio convars to absurd values that reduce or effectively disable interpolation.

Clientside interpolation exists for the purpose of smoothing out gameplay by maintaining an interpolation buffer of entity positions. Instead of displaying entities at the position they were when the server sent a packet to the client, the client will instead display entities X milliseconds (where X is your lerp value) in the past, so that if the server isn't able to send timely packets (or perhaps there's a period of increased loss or latency jitter) the client will smoothly interpolate entity positions to where they should have been (if that packet had arrived, etc).

By setting your cl_interp convars to low values, you are decreasing how much of a buffer the client gets to smooth out gameplay, and you will experience "rocket skipping".

So do me a favor: before you complain that the server sucks, check that your client settings don't suck.

Pages: [1] 2 3 ... 6