Matrix Games Forums

Oldsarge, was that with the debug build or the production build?

The release build.

Er, sorry, production build.

Thanks for the information. We will be looking into why this is going on.

I found a solution that works for me.

I have added the path to FCRS to the exclusion list for Windows Defender. So far, I've only tested this on Win7. I'll try WinX a little later.

There is something odd on a win10.

If I copy the FPRS.exe from the release 11.5 over the 10d version. Its takes more then a minute to right-click on the exe before the context menu popup. And opening the properties takes also a large amount of time.

right-click on the steam 10d version reacts as normal. The steam version have a digital signatures. The 11.5 exe don't. Can this create the problem.

We will check it out and see if the signature thing is something we can fix.

I think OldSarge is on to something here. Recently when Windows is used to unzip a file it will "Block" it if it detects it coming from another computer. This could explain the extreme slowness. To see if your program exe is affected by this, find "fprs.exe" in Windows Explorer, right click and select Properties and then look at the bottom of the tab. If it complains that it is from another computer and offers a checkbox to unblock it then check it. That part of the dialog in boxed in red below.
Check the unblock checkbox and that should help!

Also, do the exact same thing for each .DLL file just to make sure that none of them are blocked. If you find that any are then please post that here so that I can be aware of it.

This is a problem that is limited to zip files currently. The proper Matrix installers avoid these problems because they do things the long, hard and proper way.

Thanks, Rob C

Though I still won a decisive victory, this single Panzergrenadier squad (The fallen out one) managed to kill almost all of one of my MRCs, even with heavy casualties, little ammo, and very low readiness. The irony is this: Two MRCs were sent against this platoon, one moving deliberately, and one assaulting. The deliberately moving MRC dismounted and inflicted heavy casualties on the PzP, sustaining little casualties from the Panzergrenadiers itself... but not before supporting Leopard 2 fire cleaned it up.

The assaulting MRC entered the hex dismounted, suffering only 1 BMP lost...
And shut down. They became stuck within the hex, and seemed unable to damage the Panzergrenadier platoon despite losing upwards of 2-3 BMPs and their infantry every shot the Panzergrenadiers made. By the time the squad was finally fallen out, the MRC had been reduced from 30 subunits to 4.

At the same time I've been testing the effects of preparatory fires and different movement types. Artillery is working well as intended, but again I notice that a deliberate attack remains much more effective than an assaulting attack. The assaulting units typically fire less often, hit less often, and take twice the losses thanks to their "exposed" posture, whereas deliberate moving units hit more often and take only half the losses. I've made a point since 2.0.11.4 to never use the Assault command in the attack, and only use it when I want recon units to continue their course instead of screening away, or to forcefully contest a VP point.


In other, bad news, the CPU leak is back. It is not as severe as before, but now it still appears about 6 turn resolutions in, causing the FX to slow to a crawl. The only fix I have for it at the moment is saving the battle, closing the game, and re-opening both the game and save.

Stimpak, I'll pass the leak along to Rob when we chat Sunday. I will also look at assaulting movement and see if there is any obvious issue with combat when it get in hex with the enemy. Thanks for the report!

Regarding the MRC incident, pre and post battle .savs are linked here: 23 is pre-battle, 28 is after. Don't mind the gibberish I filled the operational briefing with...