Things that make you go hmmmm ...
(0 votes, average 0 out of 5)
Written by DOC   
Friday, 12 December 2008 15:28

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

 

Add your comment

Your name:
Your email:
Comment (you may use HTML tags here):
  The word for verification. Lowercase letters only with no spaces.
Word verification:
Comments (24)
1 Friday, 12 December 2008 14:33
jamieg
can i ask a simulation question is the fire being caused by the fuel igniteing in the engine?if so can we not isolate the fuel to said engine to stop the fire or do a mephis belle and put the plane into a dive to extinguish it?
2 Friday, 12 December 2008 14:39
DOC
No we can't do that at this time. It would be cool but it's not possible right now.
3 Friday, 12 December 2008 15:43
malize
no wonder your hair is like that...
4 Friday, 12 December 2008 15:46
Dover
Cool stuff, DOC. I really like these new blog-like posts that the new homepage allows. The Day in the Life of Rat HQ ones are really interesting.
5 Friday, 12 December 2008 16:33
julesr
Ah ha! I knew there was a problem when I was shooting down all those EA and not getting kills for them. I would watch them crash land a little while later and no kill. Now I know that I was not flaming them and therefor no kill. Good stuff DOC!
6 Friday, 12 December 2008 17:29
scottz@websagacity.com
Heh. Its funny how computers do exactly what you tell them to do. Congrats on squashing that bug! As a fellow programmer, there's nothing more satisfying than piecing things together like that.
7 Friday, 12 December 2008 17:39
Field Marshal Frantish
To jamieg: Diving to put out a fire works with radial engines, not most game aircraft V-12. Fuel fire on the outside of wing will be blown out, but not inside. I think it was very rare for such a maneuver to succeed, but cool. GJ DOC
8 Friday, 12 December 2008 21:16
bombguy
Reminds me of when I was a tech analyst and had to troubleshoot problems. You could look at a problem for hours and then all of a sudden, bang, the answer jumps up and kicks you in the butt. Finding the answer was almost like an adrenaline rush.
9 Friday, 12 December 2008 22:15
Sequoia3
Doc, Thank you for your dedication to this game and Congrats on your Eureka moment!
Now if you could only fix my bug! Every time I get into a dogfight I get shot down
Salute Doc and to the Staff Happy Holidays!
10 Friday, 12 December 2008 22:33
Sparky78
All interesting stuff but..... WHATS IN 1.30?? :D
11 Saturday, 13 December 2008 00:06
Tayvl
That is an interesting explanation of how things sometimes get sorted out, code-wise.
12 Saturday, 13 December 2008 01:57
soloje
Good news !
13 Saturday, 13 December 2008 01:59
Zweihund
I teach a beginning programming class at our local University. One of the first things someone asks is about game programming. I tell them they are in the wrong class.
14 Saturday, 13 December 2008 02:37
Threstep
I felt your troubleshooting pain. Worse bug to troubleshoot is of course the inconsistent one. I do love the ones such as this type that are fixed by a realization that there is really nothing wrong at all. Happy coding... ~Threstep
15 Saturday, 13 December 2008 07:53
morck
Nice to read about what's going on and I think it's important for the players to see actual examples of what devs could be spending time with. Being a programmer myself I was excited to see how the story would end :) More stuff like this please!
16 Saturday, 13 December 2008 08:28
bubi01
Hi DOC - nice work!Do you use "Use Case Modelling" in the design and build of the code modules? I found UCM & flowcharting the cases made it a lot easier to find bugs "higher up the tree"? Just wondering.
17 Saturday, 13 December 2008 09:12
lampie
The lesson here, is that one should update his own programmer manual after patches ;) Good job finding it tho, especially the YES I FOUND IT feeling! Brings back memories for me.
18 Saturday, 13 December 2008 09:23
Speed68
Doc, 1st,,"DOH !" 2nd,,Wouldn't you be able to "simulate" killing the fire, by shutting down the engines while in flight?
19 Saturday, 13 December 2008 10:53
huskerne
can we slip the aircraft to keep the flames away from the crew area (as long as it is not the center engine for the 52). If you modeled flames in you must have modeled in airflow effects to?
20 Saturday, 13 December 2008 14:36
hotel11
Very cool stuff DOC. I have begun going to school for gaming and simulation programing and found this read very interesting. Gives me an idea of what I'll be doing in the future for work. I used to be a plumber in the chicagoland area.
21 Sunday, 14 December 2008 01:04
mcafeed
Cool Beans!! this is why DOC is slowly closing on Gophur and Rafter as sexiest Rats!! Nice feedback btw.. this kind of stuff is invaluable to the gamer!!
22 Sunday, 14 December 2008 08:07
Paratus
That's a pretty cool read, Doc. It shows how remarkable the damage coding of this game really is and how much effort is needed to pull it off and create the depth of immersion we enjoy. Keep up the great work you and the rest of the Rats are doing!
23 Tuesday, 16 December 2008 17:02
Mercyman
Fix the bug Doc, it's an order S!
24 Wednesday, 17 December 2008 00:12
DOC
Ahh ... the gist of the piece was that it is fixed now. :)