HL2 Zombies and DoDS?

When I wrote scripts with EventScripts a few years ago, I tried to spawn the HL2 Zombies in a DoDS map, for fun.  Well, ES couldn’t even do that without crashing, so I thought I’d try again with SourceMod.

Reading through their forums, FoxMulder, posted a video showing working HL2 Zombies in TF2 and this intrigued me.  He didn’t want to share the code (understandable) so I had to start from scratch.

I tried spawning all sorts of npc_* entities, cycle* entities, monster_* entities.  Most were not supported by DoDS and the rest spawned zombies that’s didn’t animate.  So I had to look at a different type of entity.  Prop_dynamics can do animations so I started messing around with them.  Sure enough, the entities were spawned but they moved on the one spot…which is kinda hopeless!  Next job was to work out how to move them along, determining their velocity and make them point towards the player.  Then, once they had reached the player, to change the animation to the attack mode.
It all began to take shape.

This was the end alpha result.  Still a lot of work to do but it might be usable.

I’m not sure how to insert it into L4DoD.  Should it be a drop from a Zombie or should it spawn with the Grey Dude or should I create a whole new Zombie, replace the Gasman or the Emo and get him to spawn them all over the map.  Unlike the bots, I am not restricted in numbers, other than CPU power.  I have it set to a maximum of 64 and with the bots, my own computer chugs along, so I will have to do a lot more testing.

Friendly Fire – a blessing and a curse

I love playing with Friendly Fire.
It’s good to know that you aren’t just shooting wildly all over the place and that every bullet has to count and every bullet has to find the right target.

In L4DoD, it adds a certain level of difficulty to the game, making it harder for the US team to shoot the Zombies.  The machine gunner, in particular, has to pay close attention. With FF off, machine gunners tend the spam the crap out of targets and don’t pay attention to what is going on in front of them.  With FF on, they need to focus.

However, given the levels of 1 day bans recently, I’m figuring out that there are a hell of a lot of idiots out there.
Let me explain why.

In Left4DoD, if you team kill, the victim has five options -

• forgive,
• forgive with a slap,
• forgive and slay,
• forgive with melee
• not forgive at all.

After five unforgiven teamkills, the attacker gets a 1 day ban.  So people are either being a bunch of unforgiving bastards, which is not that likely since the stats show a large number of forgiven players or the team killer did it intentionally.

I display a message to the victim, reminding them to forgive accidents.  Accidents do happen.  It’s understandable.
It’s the intentional team killers that need to be kicked out of the game.

I was playing last night and an asshole called Cthulu (STEAM_0:0:28270417) came on the server and shot a few guys then left.  I watched HLSW on my other screen as he joined one of the other servers and shot up people there.  Then he came back.  Then he was banned.  It’s a pity that scum like that, exist in the gaming world, out to ruin other people’s enjoyment.

So friendly fire is a fun addition to the game, but it is also a curse because of the dumb asses who team kill…

Stability :)

We got stability!
And it wasn’t my plugin – which kinda pisses me off because I spent hours rewriting routines in my code!

Friendly fire is back on and I have written my own forgive routine which gives players the options of slaying, slapping, forgiving or killing/not forgiving.  It is much simpler and uses a point_hurt to kill rather than ForcePlayerSuicide (which doesn’t work in spawn in DoDS).  With a bit of lightning and some sound, it makes a good slay effect!

Those couple of days playing with FF off made me realize how important FF is part of this game.  It makes it harder to play for Allies.  They just can’t spam and shoot everywhere.  They have to think.  And that is what makes Left4DoD what it is.  I feel bad for all those players who joined and didn’t realize FF was part of the game: it always has been, from day 1, and I will always try to keep it that way.

So now I can sit down and think about a few more drops.

• ESP, allowing Allied players the chance to see through walls and spot the Zombies, for 15 seconds.
• Multiple nades…every nade thrown doubles into two more, creating a wider explosive area.
• Increased rate of fire
• Explosive barrels and props that can be picked up and thrown

Server resets fixed

Since May, I have been trying to figure out the reasons for the game crashing.
It’s so annoying to watch a server get to 16/16 and then for no apparent reason whatsoever, crash and burn.  Fortunately due to the overwhelming popularity of the game, the server refills in a flash.  But that’s not the point.  I hate crashes of any kind.  It indicates bad code and I’m anally retentive when it comes to clean code.

Whole sections of code have been rewritten to improve efficiency and to make sure there are no memory leaks, which plague many mods.  Timer functions, of which there are many, are now much improved.

Well, the past 24 hours have been good and I have finally figured out what has been causing the problems.

Friendly fire is the problem, or the SimpleTK plugin that allows players to forgive one another.
I’m not sure, yet, why but it gives me something to work on.  I have checked my code for friendly fire issues and there are none.  So either the OrangeBox is not happy with friendly fire or SimpleTK is borked.  I’ve checked that plugin’s code and I can’t see anything in it that would cause issues.  Lebson is a good coder.  So I’ll check out both for a while and see what happens.  Whatever I find, it doesn’t matter because the crashes have stopped!!

A new mode called Survival

Well, it’s hardly new, but it’s new for Left4DoD.

I have been bothered about how few humans can play on a Left4DoD server.  Annoying that in a 32 player server, only 16 people can play.

So I pondered what it would be like to open up the game to 32 players.
Of course, the only way was to go back to the old formula that Colster/Andersso and many others have used, in that when an Allied players dies, he joins Zombies.
I thought about an army of human zombies against Allies…it would be an epic slaughter…

With Left4DoD, though, you get a bunch of added benefits.
The biggest problem are the campers and people who wall themselves in a room and try to beat the timer.
In regular Zombie Mod, the Zombies only have their wits, extra health and a spade to get the final survivors.
But in Left4DoD. the Zombies have extra tools at their disposal, such as the skulls of the Anarchist carefully lobbed through windows, two Zombies spawned by the Grey Dude, a teleporting Witch and of course the terminally depressed Emo who can detonate a bomb nearby.

The bots will still be in the game but once human players start to arrive, the bots gradually disappear.

We had a play test on Thursday night with a bunch of Villuns… it was a blast as ever and I was able to tighten up a few things such as timers.

We played l33eron’s map, dod_carrion, and it is an excellent map for this mode…

Damned DoD:S

I really don’t know what VALVe did in the April 28th update.
Something really screwed up somewhere, so much so, now the engine is as unstable as BP’s reputation in the Deep South.

Everything has been double checked.  I found some illicit code in the drops routines and fixed that and now the servers stay alive longer than a couple of hours.  I tried killing the Zombie models thinking the L4D models converted over by TechKnow and Andi caused instability…it still crashed.
I tried all sorts of different code changes.

Nothing.
It is really starting to piss me off.
It’s not my code.  I’ve spent a month and a half checking and double checking.

So it might become a ‘feature’ of DoDS – the game you play for an hour then get kicked out…

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.

Latest update

Well, I have been ignoring Left4DoD since the beginning of May.
Our phpBB2 forums at TheVille were seriously outdated and needed to be renewed and updated to the more secure phpBB3.

As a result, Left4DoD took a hit and since the ill-fated VALVe update of 28 April, the plugin has been unstable beyond belief. Random crashes for which I can’t pinpoint any reason.  I thought it might have been to do with the code that showed the Zombies the location of the Human players – the see through walls code – but that code does not exist in the coop mode, which also crashes on a regular basis.

So I have several options:

1. Temporarily remove the Hunter and the skull throwing code.  The crashes might be to do with the creation of skulls and fire and then deleting them by exploding them.  There are no straggling skull and fire props that don’t delete properly and the prop count remains low.  But every time I use the skull model in DoDS, it gets crashy.  So I will remove the Anarchist from the Coop mode and watch it carefully this weekend and see if the crashing stops.  Then I can introduce the model back, without the skulls and see if that crashes.  And if that works, then I know it’s the skulls.  Alternatives might be grenades although they are not nearly as fun as the skulls….

2.  Remove the Hunter and Witch models and replace them with DoDS models for the meantime.  Those models are meant for L4D and were converted to DoDS and bring up client errors all the time.

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.