Things that make you go hmmmm ...

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

DOCWas just fixing a long standing bug yesterday, that drove me batsh*t crazy for the entire day. This happened to be the one where you need to kill all the engines in a multi-engined plane for an engine kill to be awarded to the shooter.

Sometimes it would work correctly, then 3 tests later it wouldn't ? WTF!?!?  Well the answer came to me today and it's one of those really cool moments when you are actually glad about all the infuriating stuff you go through trying to manipulate code and data to NOT act like herding cats into a box.

Ok, so you take the 3 engined Ju-52, and you test it by killing one specific engine at a time. When you kill the 3rd engine, voila! Kill awarded to shooter. That's good. You can still get an RTB (as the pilot) if you land on a friendly airfield, the kill goes to the shooter for disabling your ability to keep flying but the pilot can still RTB if he's lucky, or good, and makes it home to his airfield alive as a glider. This is how it's supposed to work.

But wait, there's more. As you work through testing all the planes, you come across the other Ju-52 and you do the same test. You kill the first engine and ... what the hell !? A kill is awarded to the shooter. But awhile ago testing the other Ju-52, it worked correctly. They use the exact same data file. Not a copy, the actual same file. How can this be ? Ok you make a note of it, and move on through the testing. All the bombers check out, except one. The Blenheim Mk.IV ... which is equally weird because the OTHER Blenheim Mk.IV (again, sharing the exact same data file) passed as correct functionality. Now this one doesn't. It's the same code!

You spend a whole day finding that every now and then, maybe 25% of the time, the result is the opposite of what it should be, and defies it's own previous test result. This is illogical! It's theoretically impossible for code to CHANGE during the same login session (not even reloading the client) ... in this manner; all by itself.

Compiler error ? That doesn't really explain it. It's not the data. Hours of examining the data for anomalies produces nothing of importance. I'm going to kill something very soon now! I have to get this stuff checked in so we can get a point release built and it's already Thursday night. Since we don't do Friday patch releases (except when we do Friday patch releases) I decide to go home, get some sleep and tackle it tomorrow.

Friday comes. I dodge the car doing a rollover flip onto it's roof on Hwy.183 (driver was cellphone dialing and swerved to avoid a truck he wandered into the lane of) ... and I make it to the office without further life threatening disasters. I start testing again. After seeing the same anomalous results (about 25% of the time) now appearing on other non-duplicated aircraft like the He-111 and C-47, I'm about ready for the funny farm.

Then it happens. A eureka moment. Two versions back, v1.27 I believe ... we fixed a long standing (7 years old) bug where a fire you started in the enemies vehicle would not award the shooter the kill, as the code couldn't see the shooter in the consequence tree (2 step traceback) it just saw the fire itself that caused the crew or vehicle demise. It could only traceback 1 step in the consequence tree. Well we fixed that, so that fires do now award a kill to the shooter that starts them. This is a relatively new KILL event that in testing *other* damage related events, we often didn't pay attention to in past years of habit; mainly because it never worked.

So I went back through all that testing from yesterday and this morning. OMG what an idiot! *facepalm* In each and every one of those instances where a *single* engine catastrophic damage event was awarding a KILL to the shooter, when all engines should have had to be destroyed ... A FIRE HAD BEEN STARTED. The fire was killing the crew! The kill award was for the fire kill on the crew/aircraft, not for the engine being taken out. It didn't test the same in every case because a fire did not start in every case. I hadn't been looking at the fires that sometimes started because I was looking at the engine kill feedback for results. Fires didn't award kills for 7 years so I totaly overlooked that feedback in watching for a kill (or not) when engines were destroyed in testing. *facepalm again*

Wow. Too frickken cool. Now if you have a twin engined bomber, and only 1 engine gets taken out, your shooter may or may not get a kill, DEPENDING ON WHETHER OR NOT YOUR PLANE IS ON FIRE. If it isn't, you might be good enough or lucky enough to limp home, and no kill to your shooter. If it is on fire, you're going down and he does get the kill.

This gives us even more variety in combat consequences and thus more immersion in the experience. Cooler features we want to have in the code, or already do have in the game that can be utilized towards better cooler possibilities and random occurances of luck and WTF?!? like real combat can and does produce.

I just thought a little story of a day in development and how it relates to what we do, and the game it makes that you love so much ... might make interesting weekend reading for a few of you.

So when this last v1.29 point release goes out (we're into v1.30 dev now) with all it's little fixes, count among them that bombers and transports DO need ALL engines killed (like it was always supposed to be) to get a kill awarded on them ... and in cases where you get a kill for taking out only 1 engine, it's because you started a fire that killed the plane and/or crew for you.

Have a good wekend and S! to everyone who loves the game, see you out there somewhere. Hopefully while not on fire.  :D

0 #24 DOC 2008-12-17 00:12
0 #23 Mercyman 2008-12-16 17:02
0 #22 Paratus 2008-12-14 08:07
0 #21 mcafeed 2008-12-14 01:04
0 #20 hotel11 2008-12-13 14:36
0 #19 huskerne 2008-12-13 10:53
0 #18 Speed68 2008-12-13 09:23
0 #17 lampie 2008-12-13 09:12
0 #16 bubi01 2008-12-13 08:28
0 #15 morck 2008-12-13 07:53
Add comment

Site Search