Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MgDark]

In the latest SVN build (atm 772 revision) if you, in a car chase you escape killing your pursuers, after the last one dies in fight, game crashes, but if you escape by leaving them behind nothing happens. Also crashes if you try to escape and 1-2 are still on your tail, then they "try" (you cant just kill elite rifle cyberterrorists with a SMG) to shot you and you kill them after that.

Another thing i found (although i dont know if they are changes or a bug) is that i have only 1 upgradeable safehouse (instead of the 2 abandones buildings in 4.07), and the fact that i cant make a squad with conservative hostages to "move them" if a raid is incoming.

[Liberal Elitist]

Oops, haven't checked this forum in awhile. I have been fixing various bugs I found but I don't think I fixed that one, I think I'll need to track that down. I do playtest the game quite a bit but I guess my style of playing the game doesn't check everything... for instance I pretty much always try to outrun other cars instead of fighting, so that code is not tested much. There have been some recent changes to code in car chases, much of it making the code more succinct and fixing some display bugs, but it's possible some of this might have caused a new bug like the one you mentioned, which would mean this bug you found is probably my fault. I will try to fix it soon.

The decrease in upgradeable safehouses was an intentional change done by someone else, probably Jonathan S. Fox, and not being able to make a squad of only conservatives is also intentional. If I recall correctly, the reasoning for less upgradeable safehouses is, there's actually plenty of safehouses if you have the Conservative Crime Squad and can take over their safehouses, plus you can take over the Crack House, and in multiple city mode you've got safehouses in every city, and if you manage to take over every apartment building, CCS safehouse, and Crack House in the entire multi-city game you end up with a TON of safehouses including a ton of upgradeable ones. In single-city mode, all 3 of the CCS safehouses are in the same city and so is the Crack House. So yeah, that was an intentional change, but not made by me, that's just the reasoning for it.

Not being able to make a squad of only conservatives... the reasoning for that is obvious. A bunch of conservative hostages who haven't been converted, going out on their own... you seriously expect them to do what you say, if you tell them to go from Safehouse A to Safehouse B, rather than running off to the cops and telling the cops all about how you kidnapped them? It's just not logical that a squad of only conservatives would be able to move around. However you CAN move squadless people around... go to (R)eview mode and "Press T to Assign New Bases to the Squadless". I think that probably works on Conservative automatons, not entirely sure. Now you can't move squadless folks to another city since moving between cities requires a car and only a squad can travel by car.

Anyway I'll see what I can do about that bug ya mentioned. I've been mostly trying to find bugs myself and not looking on the forums that often. Guess I need to check here for bug reports from folks like you more often. Thanks for the report!

[SuicideJunkie]

Something possibly related; last time I had a car chase, I was attacking with guitars.  I know I liberalized at least one of the cops following me, because they were shooting each other after a while.
After quite a few rounds, none of the chasers actually turned green and none got marked as killed, but the chase ended in success and I got a seg fault.

[Liberal Elitist]

I've managed to replicate MgDark's bug report in 2 car chases, in revision 800. So it seems that the code causing this bug has been consistently buggy between revisions 772 thru 800. It's probably in chase.cpp. So the bug must've been introduced in revision 772 or earlier. I'm pretty sure this bug was NOT present in the last beta release, version 4.07.4 beta, which was revision 730. So this bug was introduced somewhere between revision 731 and revision 772, and probably introduced in recent months (specifically, judging by changelogs, I'd say it was probably introduced in some revision starting with 756 and ending with 772). So I'm going to look at changes to chase.cpp in between revisions 756 and 772 and try and nail down exactly when and where this bug got introduced. I am well on my way to fixing it... and from what I've figured out so far, 2 people made changes to the code between revisions 756 and 772: me (yetisyny) and nickdumas. I looked carefully at every single one of nickdumas's changes back when he made them and they only introduced 1 bug which I later fixed (in revision 775 I fixed the ONE bug that nickdumas has ever introduced in revision 770). Of course I've introduced more than just one bug but fixed a lot more than I've introduced, just today in revision 800 I fixed a bug that I introduced in revision 798 for example, and that was when I was TRYING to set up a squad to go out and get in a car chase and track down THIS bug that this thread is about.

OK, so the revisions in that range where I suspect the bug was introduced into chase.cpp, where chase.cpp actually got modified are revisions 762, 764, 765, 766, and 772, all revisions that I made (none by other programmers). So at this point I'm SURE this bug is my fault. OK... so it was one of those 5 revisions that introduced the bug... now I'll look at 'em one by one and figure out which one broke it... hmm... OK I've looked thru all the changes and none of them seem to be ones that would cause this bug... I'm a little stumped... maybe I didn't introduce this bug and it was introduced in an earlier revision... OK so now I have to look at changes to chase.cpp between revisions 731 and 755 and see if maybe one of those caused it... or maybe one of the changes that I just looked at that doesn't seem like it would cause this type of bug somehow did, in fact, cause this bug... in any case it looks like I'll need to look more closely... hmm so between revision 731 and 755, chase.cpp got changed twice, in revisions 749 and 753, both by blomkvist... maybe he is responsible for this... no, I just looked at those 2 revisions, it DEFINITELY wasn't his fault. OK, it definitely wasn't 762 either, just looked at it, that was switching over from refresh(), getch(), and translategetch() to the new getkey() function. Definitely wasn't 764... that one FIXED problems in car chases and I remember testing it thoroughly then and it working quite well. Revision 765 just does harmless code cleanup not affecting functionality except for removing clearmaparea(), which I seem to recall was because I noticed that area of the screen was being erased but there aren't maps in chase mode, only in site mode, so it made no sense to call it, so revision 765 didn't cause the problem. OK now we're down to either revision 766 or 772 causing the problem. Revision 766 is just harmless code cleanup, so by elimination it must be revision 772. OK, revision 772 introduces the squadsize() and squadalive() functions and puts them to use... pretty sure that's not the problem... OK then by the process of elimination, I am completely stumped because I don't think ANY of those changes could have caused it.

Hrm... during car chases, functions OUTSIDE of chase.cpp are also called by the functions IN chase.cpp... I will have to broaden my search... this is getting super-frustrating... I cannot seem to find the cause of this bug anywhere. The first suspects to look at would be the squadsize() and squadalive() functions... OK I just looked at them, they are very short, I'm quite sure they don't have any bugs in them, and they are used in plenty of other parts of the game besides car chases and work fine in those parts...

Gah OK now I am totally stumped as to the cause of this bug... but I was able to replicate the bug myself through playtesting... well I guess I'll have to use the process of elimination along with actual playtesting... grr... usually bugs are WAY easier to fix than this one... the way I've been playtesting this bug, with the current revision, is having a full squad of 6 members armed with AK-47s do a raid on the AM Radio Station, and once there's a response, leave the site by car and then shoot at all the hicks and rednecks. That seems to trigger the bug, at least it did both times I tried it so far. Hrmph... I am quite frustrated with this hard-to-pin-down bug, but I am more determined than ever to get to the bottom of this. I think I will try black-box testing, that is, trying it with different versions of the code without actually looking at the code, to pin down which revision caused it, because when I DO look at the changes to the code in each of those revisions, it all looks like it makes perfect sense and couldn't possibly have anything wrong with it or any bugs. But it could be that in practice, the code doesn't actually do what I think it does when I look at it, and I could be missing something, so I ought to switch to a different testing method now... ugh I hate this bug, but I WILL track it down. There doesn't seem to be anything in chase.cpp that changed which would affect savegame compatibility, so if I just use older versions of chase.cpp along with the current code for everything else, maybe that can help track down which revision this happened in... either that or it could reveal that the cause of this bug isn't actually in chase.cpp but in another file instead. And the revisions of chase.cpp in that range don't seem to use any functions that have been eliminated, although new functions have been added that the newer revisions call and older revisions don't. This means the current game ought to be backwards compatible with older versions of chase.cpp and compile without any problems (by older I mean, last couple months, not revisions from a year or more ago, those would probably have more significant changes that would make them incompatible).

Well, this has been a wild goose chase so far, but I WILL solve this... I don't know how, but where there's a will there's a way, plus I'm probably the one who caused this bug even though every single change to the relevant code, I've looked at multiple times and for each change I look at I feel absolutely positive that that change couldn't possibly have introduced any bugs. I really must be missing something here... I guess it's possible this might be a longstanding bug that's been in the program longer than I think, so far I've operated under the premise that this bug was introduced by recent changes to the code. Well, I will leave no stone unturned in finding out the cause of this, until it is solved... gah... if I compare this to the bug I fixed in revision 800, for instance, well that bug was very easy to spot, very easy to track down the cause of, and I instantly knew exactly what was wrong and exactly how to fix it... I am more used to the easy-to-fix bugs like that... I am so baffled by this one right now though. Usually bugs are WAY easier to fix than this one, I've fixed many, many easy-to-fix bugs, but this one is different. Although maybe to some other programmer, it could be blatantly obvious to them, who knows?

[Jonathan S. Fox]

Gah OK now I am totally stumped as to the cause of this bug... but I was able to replicate the bug myself through playtesting...
[...]
when I DO look at the changes to the code in each of those revisions, it all looks like it makes perfect sense and couldn't possibly have anything wrong with it or any bugs.
[...]
I've looked at multiple times and for each change I look at I feel absolutely positive that that change couldn't possibly have introduced any bugs
[...]
if I compare this to the bug I fixed in revision 800, for instance, well that bug was very easy to spot, very easy to track down the cause of, and I instantly knew exactly what was wrong and exactly how to fix it... I am more used to the easy-to-fix bugs like that...

It sounds like you're debugging by eyeballing the code and running it in your head. That works for easy stuff, but sometimes you need to break out the big guns and use a step through debugger.

You use Visual Studio, right? It should be very easy to do. Set the build to Debug, hit F5 or the green play button, and when it crashes click Retry to debug. You can examine the variables in memory, look at the exact line of code it crashed on, walk up the call stack (which you often need to do to get to the proximate LCS code rather than something in an external library)... if you've never messed with step through debugging you may need to explore a bit to find your place, but it makes it a lot easier. In this case I was able to identify the cause of the crash just by reproducing it and then stepping up through the stack trace. I quickly identified the immediate cause (referencing an enemy car after it was already deleted), and on what line of what function this took place, so I could easily look at the surrounding code to see how this situation came about.

The issue was in chase.cpp in the crashenemycar() function. The delete_and_remove() function is called to delete a car prior to the text outputting the car's full name. Since the car is already deleted, its name can't be retrieved, so the game crashes. The crash bug was introduced in revision 765 when you switched that function from storing the name in a temporary variable, initialized prior to deleting the car, to directly requesting the car's name after the deletion. The two lines of code you altered made sense, but there was a line between them that caused the change to produce a crash. It's these kinds of interactions and side effects that make it difficult to spot all bugs by looking only at changes in the code.

Rather than revert the change in revision 765, I just fixed it by deleting the car later on.

[Liberal Elitist]

It sounds like you're debugging by eyeballing the code and running it in your head. That works for easy stuff, but sometimes you need to break out the big guns and use a step through debugger.

You use Visual Studio, right? It should be very easy to do. Set the build to Debug, hit F5 or the green play button, and when it crashes click Retry to debug. You can examine the variables in memory, look at the exact line of code it crashed on, walk up the call stack (which you often need to do to get to the proximate LCS code rather than something in an external library)... if you've never messed with step through debugging you may need to explore a bit to find your place, but it makes it a lot easier. In this case I was able to identify the cause of the crash just by reproducing it and then stepping up through the stack trace. I quickly identified the immediate cause (referencing an enemy car after it was already deleted), and on what line of what function this took place, so I could easily look at the surrounding code to see how this situation came about.

The issue was in chase.cpp in the crashenemycar() function. The delete_and_remove() function is called to delete a car prior to the text outputting the car's full name. Since the car is already deleted, its name can't be retrieved, so the game crashes. The crash bug was introduced in revision 765 when you switched that function from storing the name in a temporary variable, initialized prior to deleting the car, to directly requesting the car's name after the deletion. The two lines of code you altered made sense, but there was a line between them that caused the change to produce a crash. It's these kinds of interactions and side effects that make it difficult to spot all bugs by looking only at changes in the code.

Rather than revert the change in revision 765, I just fixed it by deleting the car later on.

Wow, good job finding that bug, I never would have suspected something as innocent as removing an unnecessary temporary variable that only gets used once and setting the value directly the one time the variable got used, would actually lead to any problems... I hadn't thought of the possibility that something else might happen in between those 2 events, the creation/initialization of the string variable, and the line where the string actually gets printed out, which might make the expression to find the string value actually be a reference to a deleted, null or changed object. It seemed like the most innocent, harmless change in the world that couldn't possibly produce a bug, but now that I think about it I realize, yeah, it's possible the object being referenced could get deleted or have something else happen to it in between the 2 lines that I changed, and actually, if I looked thoroughly enough while aware of this being a possibility, the line deleting said object would have been fairly blatant and obvious. Now that I realize this... well it still isn't a very obvious bug to me, but I do understand the bug and why it happened. It's not exactly the type of thing I'd expect to happen... great job finding this!

Oh and although I am a Windows user I use Code::Blocks as my IDE, with TDM-GCC as its integrated compiler/build environment/other stuff including a debugger. I don't have MS Visual Studio, doesn't it cost money? I don't have money. There's kind of a mismatch there... like when your crime squad is broke and you're thinking about an anti-aircraft gun on the roof of your compound. Oh and I haven't actually tried the debugger yet... most of the time I have no reason to. I guess I need to learn how to use the debugger, for the next time there's a bug like this. Part of why I'm not into the debugger is, the debug builds produced by the GCC compiler I use for Liberal Crime Squad... it makes debug builds that are almost 20 megabytes, that's on the order of 10 times as big as what MS Visual Studio produces. OK, more like 8 times, but still. I guess debuggers just aren't my style, I like to analyze code with my eyes and my brain, not have a computer analyze it for me. Maybe I'll use text-to-speech software so I can analyze code with my EARS and my brain, that might be an interesting change of pace, depending on how fast the computer's robotic voice talks.

Still, wow, I'm surprised/impressed you could fix that bug so fast. Just... wow. Mind... blown. Figuratively, not literally. Lots of people use the word "literally" to mean "figuratively". Yes, they LITERALLY do that. But my mind was only figuratively blown. English grammar is not so different from the grammar of computer languages like C++... and the literal meaning of C++ is "evaluate the value of C, then increment it afterwards". Sometimes when I look at some of the code, it looks like it was written in ++C instead of C++... because the for loops have ++ before the variable instead of after, at the end, which looks weird to me, although maybe that's just a personal problem since the code still works just fine either way. That is the type of stuff I think about when my mind is figuratively blown by your l33t debugging skills. Hmm... so if you know how to do programming and debugging, do you know how to do deprogramming and bugging? Those are also important skills nowadays, especially for people like me who park on the driveway and drive on the parkway rather than the other way around. Ugh... the type of text I am typing right now... this is what happens to a brain NOT on drugs. Alright, time for my medicine...

[Jonathan S. Fox]

I use Microsoft Visual C++ 2010 Express, which is free. After a month you have to register, but the only cost to registering is that Microsoft will send you an occasional marketing email pimping some developer-facing product or service.