Damned env_sprites

Well, after a month of trying to figure why the damned plugin keeps crashing after an hour or so, I figured it out for myself.
Apparently the Source engine crashes when trying to remove env_sprites, also known as the American symbol above The Infected One and  the sprites showing the Zombies where the American players are.  At first I used

RemoveEdict(entity)

and it worked for the most part, but usually after an hour or two, the server would crash…perhaps because the Source Engine was trying to remove the same entity.  So it became hit or miss.
Later I tried

AcceptEntityInput(entity, "kill")

but there was no difference in performance…after a couple of hours, the server would pack it in and reset.
All my debugging kept pointing to the same thing – removing an Allied sprite caused crashes.
My good friend MMX, a fellow server op at TheVille.Org did a good debug and his research pointed to Allied riflemen and attachments, which made sense.

I considered removing the sprites altogether, because server stability is always more important than a game feature.

Last night, after a good bath session, I changed how I made the sprites appear.
I have been aware of CTESprite temp ents for a while but figured out that I needed to be using CTEGlowSprites instead.  Setting a life of 0.1s, full brightness, with a material with the highest z-order means that the Allied sprites now delete themselves after a life of 0.1s.  Nothing to delete.  No crashes.  The game engine takes care of everything.

However, there are a few caveats.  There is a perceptible flicker as the sprite constantly updates.  In the heat of battle, it is not noticeable.  In addition, the sprite does not completely stay with the model since the sprite is getting the coords of the player and then being teleported there every 0.1s.  So when a player runs, the sprite doesn’t completely move with the player.

However, crashes are minimized and if it crashes now it usually because of a RemoveEdict or something like that.

Too strong?

I must be playing a different game from many other players.

There is a common theme running amongst some L4DoD players, these days, that when there are 4 human Zombies, they are unbeatable.

Huh?  I’ve been on Allied teams winning against 20 Zombies.  I’ve lost many rounds as a Zombie.

Kinda frustrating.  I’m trying to balance the game so that human Zombies don’t feel frustrated dying time after time, while the Allies still feel like they can beat the hordes.  I’ve reduced human Zombie health, no longer tying it in to the number of times they’ve died, like the bot Zombies.  Their abilities take longer to recharge.
And yet some people are still complaining.

So I think I need to look at introducing and removing human Zombies gradually.
Right now, the current system doesn’t work well.
When the Allies get to 7, the next player can join Zombies.  Soon it can be 7 to 4 (16) which is overwhelming for many Allied players, particularly for those who are just in it for the achievements.

So the way I will deal with it will be like this:
Allies: 7        Axis: 0         Total: 7
Allies: 7        Axis: 1         Total: 8
Allies: 8        Axis: 1         Total: 9
Allies: 8        Axis: 2         Total: 10
Allies: 9        Axis: 2         Total: 11
Allies: 9        Axis: 3         Total: 12
Allies: 10        Axis: 3       Total: 13
Allies: 10+      Axis: 4       Total: 14

Hopefully this won’t feel as bad to the Allies…

Exploits and crap

Hehe!
Every time I introduce something new (in this case, players going on fire because of the flaming skulls), someone, somewhere will find a way to get around it!  Word quickly spreads as players help each other out.

In this case, players quickly learned to go prone to put out the flames.  It wasn’t planned to do that – it was an exploit.  And just as I was about to introduce a new fire extinguisher drop from the Zombies, too!  So I canned the fire extinguisher and I also canned the fire from the skulls.

There was a number of reasons:

• Players like instant pain rather than long drawn out pain.  They’d rather be blown up and die immediately rather than slowly losing health to a fire
• Having the fire meant multiple handles from datapacks and although I was meticulous at closing them, it doesn’t take much to miss the odd handle causing the plugin to crash
• Players often asked why they were on fire – as I’ve said before in game design, players should know at all times why they are getting injured or dying.  VALVe went to a lot of trouble putting in the deathcam shots plus information on the weapon used
• It was difficult to figure out whether the fire was from a Molotov or a skull

So instead, the skulls now explode after a 2 second fuse.
Over the next few days, I’ll adjust the strength of the skulls.

I also changed the code so that the Grey Dude’s teleported Zombies will go back to where they were if the player inadvertently teleports them into a wall or door frame.  Using the same code, the Witch will do the same.

No more twitchy

The bots have always been an issue since the day VALVe put them in the game.
You know the way they work.  They wander around aimlessly, bumping into walls and generally being as useful as a screen door on a submarine.
I modified them so they run around the map where I want them to move, but there was always the fight with that VALVe aimless code.  The result was the twitching, the constant twitching, that prevented them from walking through archways and doors.  The bots would continually run around swinging their spades.

Until now.

I figured out, last night, how to change it so that they only swing when they get close to players.
And better than that, I also figured out how to get them to sprint when they close to a player.  What we end up with is an interesting change to the Zombies bots.
No more twitching and they have a purpose!

Flames and fireballs

Another Boss
As some of you know, I enjoy sitting in the bath pondering how to do code-related stuff and I was thinking about the need for a sixth Zombie boss so that it’s not always just Witch, Grey Dude, Gasman, Infected One and Emo… It needs another.

So I thought of a Zombie that can fire fireballs.  How the heck could I do that?
Well, I could spawn a small env_fire and teleport it across the map.  Working out the vectors and landing spots wouldn’t be an issue.  Spawning an env_fire at the receiving end wouldn’t be an issue.  I just need to work out how to move the flame through the air!

Maps
l3eeron, one of the Ville’s resident mappers (talented mapper with a gift for visualization and knows what makes a great map) has made a small map for us called dod_carrion.
Very spooky and creepy and the Allies have a tough time defending!

It is still undergoing play tests but it will soon be ready and released with L4DoD.

So what’s been going on?

It’s been a while since I posted anything here and with me being off work for vacation, I thought I’d throw in some updates between my endless house decorating.

L4DoD
The regular co-cop version has ended its production cycle.  I don’t feel there’s much more I want to do with it simply because it isn’t as much fun for me to play and I’m fed up with players using it purely as an achievement plugin.  They simply don’t want to cap flags, rise to the challenge of defeating Zombie hordes.
They just want to sit in windows, where the Zombies can’t reach and shoot Zombie after Zombie, bitching and whining when a Zombie kills them with a shovel, or the Witch comes up behind them.
So there will be no further updates.

L4DoD Versus
This is simply fun to play.  If players want to sit back and cap flags, well, they have four opposing Zombie players who will cap back. Wanna get achievements, well, then you are going to have a challenge because these Zombies can go through doors and hallways!
It still requires a lot of tweaking and the balance is not quite right, but it is getting much better.  It is very much still in Beta because the game testing in this needs a lot of work.

For example last night, I was playing as Grey Dude and I was cutting through the Allies like butter, and yet, while playing as Witch, I couldn’t get near the Allies because of the low health.  So I have to figure out that stuff too.
In the meantime, I’m working on ESP for the human Zombies so that they can see where all the Allied players are through walls, etc.  I have also added a health read-out since the human Zombie doesn’t know how much health he has..

So watch this space!

New mode – Left4DoD Versus

This has been on the cards for a while.  I get constantly asked why humans cannot play Zombie like in the Left4Dead versus mode and the main reason is that it would require a major rewrite to get the game mode working properly.  Everything has been tailored to bots and getting humans just to play the five special infected requires a different way of thinking.

So I had a bath.  Those of you who know me, know that this is where I get 90% of my inspiration and true to form, I thought of a way it could be done.

The deal is this.  There can only be four special infected on the Axis team at any one time so a bunch of things need to be controlled:

1. Every one needs to be able to play a special zombie at some time, so randomly swapping people is a good way of doing it.  If not, people complain they never get to play Zombie…and they do complain.
2. Zombies need to be a lot easier to kill.  Special Infected now have intelligence meaning they can hide, sneak around, get to areas of the map quickly, go in places where the bots can’t go.  So they have to be weaker.
3. Allied guns need to be more powerful to deal with the specials.
4. Spade hits need to be weaker for Special Infected.
5. You should not have Special Infected until Allied server numbers increase.

So we have a test server running the Beta right now:
69.162.99.28:27015 TheVille.Org XV – Left4DoD-Versus Zombies

To be honest, it’s not as popular as Co-op for some reason.  I’m getting the impression that people just like to go, shoot bots and get achievements, rather than face a challenging map (the Allies do lose more frequently).
So more tweaking is going to have to be done over the next while.

Well that was embarrassing

You think you have every base covered when you upload a new version of the plugin.

But nothing prepared for the dumbassed bug I added to the plugin.  Somehow, in some weird editing screw up, I deleted the line where Zombies slowly get more health as they die.
For for two days straight I couldn’t figure out why players were racking up 400+ kills…

I changed the program and with Squeeeeze’s and Oldman’s help I managed to get the levels back to where they should have been before the bug.

*sigh*

New content

I added two new items for players this weekend:

Pills
The player who picks these up, gets faster speed for a brief period of time.  I’ve actually noticed a bug in it, while playing last…it is supposed to give them full health for a brief period of time and so that needs to be fixed!  You try to think of everything…lol

Zombie Blood
VALVe could use this one in L4D/2 …A player picks up Zombie Blood and it makes him invisible to the Zombies – they don’t target him.
In Left4DoD, players have found this incredibly useful for capping those difficult last flags like in Avalanche or Anzio.

The items are Zombie drops.
The Pills drop 1 in every 10 while the Zombie Blood drops with a 1 in 50 chance.  You pick them up, you use them.
Now I hear some of you saying, why can’t I keep them,  to use whenever I want?

Well there’s a reason for that.
In DoD:S, I am unable to add extra weapons/items, draw a hand holding it, give it a slot, add it to the next item on the mousewheel.  It’s just not do-able with SourceMod.  I would need to completely re-write the game and add my own stuff in C++.

Ah, you say, why not create a command like use_blood or something?
I learned from my experience with DoDS:RPG, 3 years ago, that multiple binds for players drive them crazy.  Servers can’t create the binds since the server has no access to the client’s config.  So players have to create the binds themselves.  Binding a key to use_blood or use_pills would be simply off-putting and not user-friendly.  The whole point of the game is to keep it as simple as possible – so that anyone can walk in, shoot Zombies with no binding.

So the current method is far simpler and a more rewarding experience.
Besides, the added randomness makes it so much more fun!

Still to do this week:
Achievements: heading for the bath to have a good think about that one
Voices specifically for helping players identify the Emo coming

Tidying up a few bugs

There are a couple of bugs that I have been neglecting for the past few weeks while I’ve been updating TheVille.Org’s web server and stats.

One of these is the gas glitch.  The Gasman dies, the gas cloud dissipates and yet in certain areas on the map, players still experience the gas effect, usually because the Gasman’s timer has not killed itself. So I rewrote the way it happens.
Now it should be much more reliable and it also means less resources are being used by the server.
At one point, during testing, I also made the gas choke the player, causing damage.  Maybe this might be preferable to just having your vision buggered up, but I left it out simply because players wouldn’t know why they were getting damage.

The Molotovs had been annoying me for a while.  One of those “Damn I must fix that” things!
I rewrote the whole routine so that now players get credited with a Molotov kill.  I also shortened the time it takes to burn a Zombie.
I have had one or two requests to do something about the Molotov in spawn, where a griefer burns his team.  Immature and not in the spirit of co-op.  So to counteract this, any Molotov in spawn does not burst into flames.  I may look at hooking it into the TK system.
The fact is that this is a friendly fire game, much like L4D is.  I want it to remain friendly fire so that we can keep ‘The Infected One’.

Another issue has been a small problem with waypointing.
I had it that if a bot jumped twice, and couldn’t reach the target, it would forget the target and go to the next point.  But for some inexplicable reason, they would suddenly appear in the middle of the map and drop down.  It happened in Avalanche and Donner, specifically.
So I removed that part of the code and now they just forget the target, look for the next waypoint and keep moving.

The code is stable and running well and soon, I’ll move it up from Beta.