Please help

[Tuskerlove]

I need some techincal info.

I bought a new computer and when I went to reinstall my Dominions II game - I received this error on initialization

Installer verification failed.

This could be the result of an incomplete download, a failing disk, or (possible) corruption from a virus.

You can try to force an install using the /NCRC command line switch (but it is not recommended).

Has anyone ever run into this problem? I don't see any scratched on the Dominions II disk so I don't understand why it's not working.

Any help would be very appreciated as this is my favorite game and I can't stand that I can't play it.

I installed the new Direct X
Checked for viruses
No need to resurface the disk as I see nothing wrong with it

Thanks in advance,
Tuskerlove

[Gandalf Parker]

What operating system and Version?
Mac? Solaris? Linux? Windows?

[Arryn]

Originally posted by Gandalf Parker:
What operating system and Version?
Mac? Solaris? Linux? Windows? <font size="2" face="sans-serif, arial, verdana">Since he installed DirectX, it must be some flavor of Windows. Perhaps it's related to the new "copy-protection" that IW inflicted on us in a recent patch?

[Gandalf Parker]

Originally posted by Arryn:
Since he installed DirectX, it must be some flavor of Windows. Perhaps it's related to the new "copy-protection" that IW inflicted on us in a recent patch? <font size="2" face="sans-serif, arial, verdana">On install? I dont think anyone has come up with anything to stop an install on a new machine. Even if it was a re-install such blocks on Windows machines tend to be registry blocks

Ive installed my Dom discs many MANY times. On the same machine, different machines, different major operating systems even. I dont think the protection for it kicks in until you try to play it.

[Arryn]

Originally posted by Gandalf Parker:
On install? I dont think anyone has come up with anything to stop an install on a new machine. Even if it was a re-install such blocks on Windows machines tend to be registry blocks<font size="2" face="sans-serif, arial, verdana">If an app/dll that is called by the installer fails to run, the install *will* fail. I have seen this happen. Amongst the many years of software experience I have, 5 years of it is in writing installers for Windows systems. I assure you that installs can and do fail, under the right (wrong?) circumstances.

As a for-instance, suppose the installer were to check for an active net connection via network API calls. If the user does not have a working net connection (say, for a registration code or copy-protect check), the net API call will return false or fail. Depending on how the installer was written, the install could fail. And fail with an error message not dissimilar to what Tuskerlove is reporting.

I suspect that only the folks at IW are going to be able to definitively answer his question. All we can do is guess.

[Norfleet]

Originally posted by Tuskerlove:
You can try to force an install using the /NCRC command line switch (but it is not recommended).<font size="2" face="sans-serif, arial, verdana">You've answered your question.

If at first it doesn't work, force it. If it breaks, it needed to be replaced anyway.

[Norfleet]

Originally posted by Arryn:
If an app/dll that is called by the installer fails to run, the install *will* fail. I have seen this happen. Amongst the many years of software experience I have, 5 years of it is in writing installers for Windows systems. I assure you that installs can and do fail, under the right (wrong?) circumstances.<font size="2" face="sans-serif, arial, verdana">Pah! In the old days, installing things didn't involve wonky executables just for installing, or DLLs. Installations couldn't "fail", because you simply copied everything into the directory of your choice.

What, may I ask, was wrong with this system? It was foolproof and flawless, yet they had to can install some crazy new-fangled "installer", when something as simple as untar/unzip/copy would have worked fine!

[Arryn]

Originally posted by Norfleet:
Pah! In the old days, installing things didn't involve wonky executables just for installing, or DLLs. Installations couldn't "fail", because you simply copied everything into the directory of your choice.

What, may I ask, was wrong with this system? It was foolproof and flawless, yet they had to can install some crazy new-fangled "installer", when something as simple as untar/unzip/copy would have worked fine! <font size="2" face="sans-serif, arial, verdana">In the "old days", you had crappy, grossly-unstable OSes like DOS/Windows, or Windows 9x (still DOS-based, essentially). OSes that didn't care if you overwrote key system files (that shouldn't be) or installed drivers that are incompatible with other drivers. I could go on and on about the shortcomings of the M$ OSes prior to WinXP, but this isn't the forum for such, and, frankly, I've better things to do.

The short answer as to what the big deal is today with needing a sophisticated installer can be summed up in two words: Windows Registry. The long answer involves *why* this is important, and an entire college-level course on the subject can be taught.

Since, AFAIK, you (Norfleet) aren't a sofware engineer, much less have extensive knowledge of Windows OS internals (there are many books on this subject alone), nor ever actually wrote an installer for a modern Windows application, you really have no business judging that which you know zilch about. Of course, knowing you to be the cantankerous old curmudgeon that we're so fond of, that most assuredly would never stop you from doing so. http://forum.shrapnelgames.com/images/icons/icon12.gif

[Norfleet]

Originally posted by Arryn:
In the "old days", you had crappy, grossly-unstable OSes like DOS/Windows, or Windows 9x (still DOS-based, essentially). OSes that didn't care if you overwrote key system files (that shouldn't be) or installed drivers that are incompatible with other drivers. I could go on and on about the shortcomings of the M$ OSes prior to WinXP, but this isn't the forum for such, and, frankly, I've better things to do.<font size="2" face="sans-serif, arial, verdana">Pah, so? It's my computer. If I want to install incompatible drivers and arbitrarily delete things at whim, I can do that. Certainly this won't happen when installing a program this way, since everything goes in the program's own directory. That means the only way a system file or driver that's "incompatible", and I use this word in quotes for a reason, gets overwritten, is when *I* choose to overwrite it!

Just as an example, in the *OLD* days, and it's still true on Linux, when you wanted to delete something, you deleted it, and it went away. Now, Windows tries to pretend it's smarter than you are, and tells you that you CAN'T delete it, blah, blah, blah, because it's in use, blah, blah, blah. Like I'm supposed to care. So what if a program malfunctions as a result? Clearly, if I'm ordering the deletion of the file, I'm aware of the consequences of doing so, and simply am not concerned that some program, which I undoubtedly didn't like anyway, or I wouldn't be deleting its files, will break. In fact, that's the entire point!

And grossly unstable my ***. DOS NEVER CRASHES! Never! Ever! Programs crash. DOS doesn't. Same cannot be said for Windoze!

The short answer as to what the big deal is today with needing a sophisticated installer can be summed up in two words: Windows Registry. The long answer involves *why* this is important, and an entire college-level course on the subject can be taught.<font size="2" face="sans-serif, arial, verdana">Pah. The Windows Registry is a pile of crap. Linux doesn't have a registry that programs arbitrarily write crap into, and programs in Linux instead use something called a "configuration file"! What a novel concept, that items pertinent to the program are written in a file in the program's own directory, instead of all other the place! Amazing how such a simple concept works so well.


Since, AFAIK, you (Norfleet) aren't a sofware engineer, much less have extensive knowledge of Windows OS internals (there are many books on this subject alone), nor ever actually wrote an installer for a modern Windows application, you really have no business judging that which you know zilch about.<font size="2" face="sans-serif, arial, verdana">Pah. You think I've never programmed anything? I program lots of stuff....and it installs by UNZIPPING OUT OF A FILE! Amazing how such a simple and ancient concept works so effectively, even in the day and age where people needlessly add points of failure to what is otherwise a simple operation.

Case and point: I've installed Dom2 perfectly fine by simply unzipping it out of a zip file, from when I packaged my previous directory and shuffled it off to another computer. Amazingly, it works. So why do we need an wonky installer? Pah! If it really had that many files, there was an ancient method called "INSTALL.BAT". Once again, no wonky executables, and if you wanted, you could open it up and do it manually!

Of course, knowing you to be the cantankerous old curmudgeon that we're so fond of, that most assuredly would never stop you from doing so. http://forum.shrapnelgames.com/images/icons/icon12.gif <font size="2" face="sans-serif, arial, verdana">Us cantankerous old curmudgeons have this annoying habit of remembering that in the old days, these problems didn't exist, and why they didn't occur.

[ July 19, 2004, 00:17: Message edited by: Norfleet ]

[Arryn]

Originally posted by Norfleet:
And grossly unstable my ***. DOS NEVER CRASHES! Never! Ever! Programs crash. DOS doesn't.<font size="2" face="sans-serif, arial, verdana">If an app crashes and takes the OS with it, that's also an OS crash. A properly-written OS won't allow an app to corrupt the OS. Your wonky memory may not permit you to recall it, but DOS apps could very easily crash DOS. I remember games like X-COM and Panzer General doing it, just to name two. If you think differently, then you're deluding yourself (or worse).

BTW, DOS, even running no apps, could crash too. Hard to do, but it was possible. All depended on the stability of what was loaded using the config.sys file. Then there's infamous DOSes like DOS 5.0 (fixed in 5.1 IIRC), 6.0 (fixed, sort of, in 6.01), and 6.2 (fixed in 6.22).

[Norfleet]

Originally posted by Arryn:
If an app crashes and takes the OS with it, that's also an OS crash. A properly-written OS won't allow an app to corrupt the OS. Your wonky memory may not permit you to recall it, but DOS apps could very easily crash DOS.<font size="2" face="sans-serif, arial, verdana">Meh, you act as if Windoze applications don't regularly crash the entire computer as well. DOS, however, doesn't come with any perceptible loading time even on the crummiest computer. You turn it on, and it runs! For the reason, such features were not necessary.

I remember games like X-COM and Panzer General doing it, just to name two. If you think differently, then you're deluding yourself (or worse).<font size="2" face="sans-serif, arial, verdana">X-Com still crashes and takes out the entire computer at times, even in Windoze.

BTW, DOS, even running no apps, could crash too. Hard to do, but it was possible. All depended on the stability of what was loaded using the config.sys file. Then there's infamous DOSes like DOS 5.0 (fixed in 5.1 IIRC), 6.0 (fixed, sort of, in 6.01), and 6.2 (fixed in 6.22). <font size="2" face="sans-serif, arial, verdana">Not so. DOS, running nothing, sat there and blinked. It could do this for weeks. Months, years. Never crashing. Starting with Windoze 9x, that ended: Windoze can now crash even if left completely unmolested.

[Arryn]

What M$ OS are you running now? And if it's XP Pro, what app(s) have you found that can take out the OS when the app crashes? I'm sincerely curious as I've yet to find one.

[Norfleet]

Originally posted by Arryn:
What M$ OS are you running now? And if it's XP Pro, what app(s) have you found that can take out the OS when the app crashes? I'm sincerely curious as I've yet to find one. <font size="2" face="sans-serif, arial, verdana">I mentioned X-Com, of course, although there are several other cases of a program crashing, immediately setting off a BSOD and taking out the rest of the operating system with it. I've had this happen in GalCiv also, and several others whose names elude me at this moment.

[Cainehill]

Originally posted by Arryn:
[QBThe short answer as to what the big deal is today with needing a sophisticated installer can be summed up in two words: Windows Registry. The long answer involves *why* this is important, and an entire college-level course on the subject can be taught.
[/QB]<font size="2" face="sans-serif, arial, verdana">And even Microsoft has finally realized that the registry was a colossally bad idea; with the .Net compilers, the preferred install goes back to using something much more similar to the old .ini (or unix .cshrc) type files.

This is even for real applications. And _why_ did a game ever need to be put into the registry??? Install Solitaire, possibly destroy your computer because it updates the registry. Or because it updates the registry after you save a game, in order to update the Documents submenu for a recently used file.

Use of the Registry slowed down computer boot times, increased complexity, increased chances of catastrophic failure. Sure, _some_ things deserved to be in something like a registry - if a program handles a certain type of file, for instance.

But the options and settings for the program itself should never have been in the registry. 10 years later, Redmond's blunderers finally start to realize this.

[Mad_Lear]

Well, back to the original topic, did you try simple things like a cleanboot ( http://support.microsoft.com/default.aspx?kbid=310353 for XP- just make sure to hide those Microsoft services, and, just between you and me, leaving those ".ini" files alone might not be a bad idea; there are other equivalent articles for the other O/S's, of course, except for Win 2000) or disabling the antivi (make sure you are firewalled before trying either of those steps- the plain-jane XP firewall would do for a short haul like an attempted dom2 installation)?

Antivis, in particular, can cause all sorts of problems, especially if you have it configured to be restrictive- Norton Internet Security, for example, can change the permissions of certain key registry keys, so that user-initiated programs (or, for that matter, just cracking-open regedit and trying to edit certain keys) will fail. Also, the tried and true method of installing from a flat (copying the whole disk to a directory on drive 'c:' and running the installation from there) could weed out a wonky CD drive (new computers tend to get dropped/trampled/played ping-pong with in transet, so they often arrive as broken computers) or, alternatively, a CD so fancy and fast it outruns the installer.

Finally, if it's a new computer, make sure your manufactured didn't screw you with a "user friendly feature" like a pre-partitioned hard-drive with a 500 meg "c:\ drive" or a pre-made user account with limited permissions- I kid you not, I've seen companies sell computers with setups like these, thinking all the time that they are making things easier on the buyer.

I know most of this is pretty basic, especially considering how computer-literate most of this forum is, but I just had to bring it up, since 90% of the time, the basic stuff is the bread-and-butter of getting past most problems. I mean, no need to track down the specific problem .dll file or registry key, when you can just shut down most of the crude in the background with a cleanboot and take out the problem program/process purely through colatarol damage! http://forum.shrapnelgames.com/images/icons/icon7.gif

BTW, a spyware sweep with a good program (links to a few good ones can be found at www.microsoft.com/spyware (http://www.microsoft.com/spyware) ) might not hurt as well. Spyware are the devil- they aren't as mean as viruses, but they are often much more subtle, and put up just as much of a fight when you try to remove them...

Anyway, just a few simple suggestions from a less philosophical, more pratical perspective! http://forum.shrapnelgames.com/images/icons/icon10.gif

[alexti]

Originally posted by Arryn:
What M$ OS are you running now? And if it's XP Pro, what app(s) have you found that can take out the OS when the app crashes? I'm sincerely curious as I've yet to find one. <font size="2" face="sans-serif, arial, verdana">Well, Visual Studio from the same MS does it just fine. Just try take a breath while debugging some system wide hook. That nasty breakpoint-in-template multiplying bug in VC is also quite efficient. While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.

Generally, while NT/2000/XP are somewhat more stable (than DOS/Win95+), my development computer can rarely survive for more a week without a reboot. Even without working with system hooks or drivers (not that I actually work on drivers).

[Arryn]

Originally posted by Norfleet:
</font><blockquote><font size="1" face="sans-serif, arial, verdana">quote:</font><hr /><font size="2" face="sans-serif, arial, verdana">Originally posted by Arryn:
What M$ OS are you running now? And if it's XP Pro, what app(s) have you found that can take out the OS when the app crashes? I'm sincerely curious as I've yet to find one. <font size="2" face="sans-serif, arial, verdana">I mentioned X-Com, of course, although there are several other cases of a program crashing, immediately setting off a BSOD and taking out the rest of the operating system with it. I've had this happen in GalCiv also, and several others whose names elude me at this moment. </font><hr /></blockquote><font size="2" face="sans-serif, arial, verdana">You didn't answer re: what OS you use. I can't get X-COM to work under XP Pro. But it doesn't take the OS out. At least not on my machine. Different hardware (and drivers) behave differently (an obvious statement that's not always obvious to everyone), so my eXPerience may not be typical. OTOH, I go out of my way to cherry-pick hardware components to make a stable machine. (Tom's Hardware helps a lot with this.)

[Arryn]

Originally posted by Cainehill:
Use of the Registry slowed down computer boot times<font size="2" face="sans-serif, arial, verdana">Not significantly, if you have modern HDDs and MBs. Running XP on a very old system, at the minimum spec, is another matter. (The worst culptit, though, isn't the Registry but all the device drivers that must be loaded.) My XP Pro system boots to the desktop in well under a minute, a helluva lot faster than my Win9x box that has a far smaller Registry.

increased complexity, increased chances of catastrophic failure.<font size="2" face="sans-serif, arial, verdana">Only if the programmer doesn't fully understand what's s/he's doing. Which, alas, is the case for 90%+ of all applications since most dev shops don't have people on staff that are experts at OS internals, or even if they do, they aren't the ones writing the install code.

[Graeme Dice]

Originally posted by alexti:
While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.<font size="2" face="sans-serif, arial, verdana">Well, if you're writing low-level software, then it's possible to crash just about any OS. Try making an I/O thread that runs at a higher priority than the kernel in *nix based systems for example.

[Arryn]

Originally posted by alexti:
Well, Visual Studio from the same MS does it just fine. Just try take a breath while debugging some system wide hook. That nasty breakpoint-in-template multiplying bug in VC is also quite efficient. While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.

Generally, while NT/2000/XP are somewhat more stable (than DOS/Win95+), my development computer can rarely survive for more a week without a reboot. Even without working with system hooks or drivers (not that I actually work on drivers). <font size="2" face="sans-serif, arial, verdana">The culprit is that M$, in their infinite (lack of) wisdom, never coded the OS (any of them) to make proper use of the Intel multi-ringed processor security architecture. The Windows OS kernel is not fully isolated from the rest of the OS, running in Ring 0 as it should. Windows' kernel and low-level device drivers are intermeshed and both run at the same processor priority/security ring (unlike linux). XP is better than 9x in that at least the apps themselves (not the device .dlls the apps may call) run in a different ring and thus are insulated from the rest of the OS. But even in XP, apps that have bad drivers can take the OS with them since the driver code runs alongside the kernel code.

MSVS interfaces with the OS at low levels, especially the debugger (something MS tells devs not to do with their own code, but MS is big on breaking their own "rules"), and thus can readily corrupt the kernel code. I've never crashed XP using VS, but I don't work on drivers either. I was too hasty in saying that I didn't know of any apps that crashed XP Pro, since I'd forgotten that VS has the capability to do so when used certain ways. Thanks for the reminder. (OTOH, in my defense, when I mentioned apps, I was thinking of end-user apps such as games and "productivity" apps.)

[Esben Mose Hansen]

Arryn: I like linux as much as the next man, but linux is only a little better than windows with regard to what runs at ring 0/1. In fact, all kernel modules run in the same ring as the kernel itself: it is monolithic. BSD is the same. If you want a microkernel, which does not exhibit this problem, you want HURD or other exoteric kernels. Last time I heard, (true) microkernels have a 20% performance hit (according to Tannenbaum as far as I recall)

Graeme Dice: It is getting difficult to crash a modern, hardened linux system. E.g, fork-bombs doesn't work anymore. The trick you mention I do not understand. The kernel has no thread or process as such; so I don't understand how you can determine or exceed it's prioty?

[Sheap]

As far as what runs in what ring, it isn't really that big a deal. First, most modern CPUs have only 2 rings, so if your OS is intended either for platform independence or targeted at a 2-ring CPU, you don't have a choice. This is pretty much everybody except Windows. Secondly, one of the reasons many CPU designs have only 2 rings, is because having extra rings isn't really all that useful. As evidence you can look at free Unix type systems, and note their great stability, yet they all run in 2 rings only. What should they be doing that they aren't, and how much real-world improvement would it give?

[Arryn]

Originally posted by Esben Mose Hansen:
Last time I heard, (true) microkernels have a 20% performance hit (according to Tannenbaum as far as I recall)<font size="2" face="sans-serif, arial, verdana">Esben: One of my biggest beefs with MS is that they have always favored performance over stability (hence allowing drivers and apps to run at the same level as the kernel). What good is software that loads a second or two faster if you never know when it'll crash your system?

Sheap: when did Intel switch from 4-ring to 2? I haven't followed CPU hardware all that closely in a number of years. The 386 processors had 4 rings, and I believe the 486s as well.

http://www.dominions-2.org/images/ia32.gif

The basic problem is that MS OSes never used more than 0 and 3 (sticking what should have been in 1 & 2 in 0 where it shouldn't have been), so I presume that Intel (who was in partnership with MS for quite a while) eventually gave up the idea in order to simplify their designs if MS wasn't going to use the feature.

[Esben Mose Hansen]

I also fail to see what you gain from the middle rings. The discussion is mostly what should be in ring 0 / kernel space and what should be in ring 123 /userland.

Another problem is that people think that moving something to ring 0 improves performance (anybody remember the HTTPD module?), but in reality, this is not always so.

But I am no expert in OS design; I regret that HURD is becoming increasingly irrelevant, as it has some interesting ideas. Besides, I'm spoiled: I dislike having to reboot just because I have upgraded my kernel http://forum.shrapnelgames.com/images/icons/icon10.gif

[Graeme Dice]

Originally posted by Esben Mose Hansen:
Graeme Dice: It is getting difficult to crash a modern, hardened linux system. E.g, fork-bombs doesn't work anymore. The trick you mention I do not understand. The kernel has no thread or process as such; so I don't understand how you can determine or exceed it's prioty? <font size="2" face="sans-serif, arial, verdana">Make a blocking I/O thread that will never return control to the Kernel, and that intercepts all interrupts and ignores them. It might not be doable on all unix based systems, but I know that it was under Darwin just two years ago.

[Tuskerlove]

Thanks all for the input. I'm only partially computer literate (King Lear) so I'll try all the things you suggested. Hopefully, I can get it installed. I can always contact customer service and see if someone can walk me through how to use the

/NCRC switch.

I'm sure this is illegal but I have to ask - am I allowed to download the program off of Kazaa or someplace and use my cd key to prove I own the software? I have already registered the game with the company so they have all my pertinent info plus the sales receipt and packing list.

I jsut don't want to spend another 50+ to get the game again if I can avoid it.

Again you guys are the greatest!

Thanks

Tuskerlove,

Please contact Annette at the Customer Service:

http://www.shrapnelgames.com/cgi-bin/Wonderdesk/wonderdesk.cgi

She may be able to help you with finding something out about your copy of Dom2, or CD-key, registration, etc.

[alexti]

Originally posted by Graeme Dice:
</font><blockquote><font size="1" face="sans-serif, arial, verdana">quote:</font><hr /><font size="2" face="sans-serif, arial, verdana">Originally posted by alexti:
While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.<font size="2" face="sans-serif, arial, verdana">Well, if you're writing low-level software, then it's possible to crash just about any OS. Try making an I/O thread that runs at a higher priority than the kernel in *nix based systems for example. </font><hr /></blockquote><font size="2" face="sans-serif, arial, verdana">The best way to kill *nix that I've experienced was to have bug in "fork" logic that caused my process to multiply exponentially. I've tried to kill them manually, but I was losing the race frantically typing kills. Apparently sysadmin didn't set any quotas on processes, so my application was gradually taking over big Solaris server. Luckily, the server has enough life force to survive until I've paused to think and to figure out that I could do better than doing kills from the console http://forum.shrapnelgames.com/images/icons/icon7.gif

But I think that a lot of those kind of problems can be protected against on properly configured *nix system. Not if you're writing the kernel yourself, of course, though.

[Norfleet]

Originally posted by alexti:
The best way to kill *nix that I've experienced was to have bug in "fork" logic that caused my process to multiply exponentially. I've tried to kill them manually, but I was losing the race frantically typing kills. Apparently sysadmin didn't set any quotas on processes, so my application was gradually taking over big Solaris server. Luckily, the server has enough life force to survive until I've paused to think and to figure out that I could do better than doing kills from the console http://forum.shrapnelgames.com/images/icons/icon7.gif <font size="2" face="sans-serif, arial, verdana">Heh, you mean something like "kill -9 -1"? I'm surprised that it took so long. You'd think that the faster the server was, the faster it would devour its own resources. Although maybe your program wasn't quite as directed as something like "while(1) fork();"

[alexti]

Originally posted by Norfleet:
</font><blockquote><font size="1" face="sans-serif, arial, verdana">quote:</font><hr /><font size="2" face="sans-serif, arial, verdana">Originally posted by alexti:
The best way to kill *nix that I've experienced was to have bug in "fork" logic that caused my process to multiply exponentially. I've tried to kill them manually, but I was losing the race frantically typing kills. Apparently sysadmin didn't set any quotas on processes, so my application was gradually taking over big Solaris server. Luckily, the server has enough life force to survive until I've paused to think and to figure out that I could do better than doing kills from the console http://forum.shrapnelgames.com/images/icons/icon7.gif <font size="2" face="sans-serif, arial, verdana">Heh, you mean something like "kill -9 -1"? I'm surprised that it took so long. You'd think that the faster the server was, the faster it would devour its own resources. Although maybe your program wasn't quite as directed as something like "while(1) fork();" </font><hr /></blockquote><font size="2" face="sans-serif, arial, verdana">Yeah, it was much better camouflaged, but they key was that the each process was establishing communication with the spawned process before spawning a new one. This required to do some work before, and as the server was getting loaded more and more whole thing started to slow down which gave me a breath http://forum.shrapnelgames.com/images/icons/icon7.gif