Matrix Games Forums

ORIGINAL: Ramses

I have experienced a couple of ctd's after playing trying to play out the scenario from the savegame i sent you. But I got a new game stoppage that I have never seen before, not sure if it counts as a ctd. Being out of memory seems odd because In run the game on a corei7 with 8 gigs of ram.



Update: I can not pinpoint a single action that leads to a ctd. It does seem that every time it happens, the Gutmann hq is involved. Maybe the new code will prevent this from happening. I'll try to get to a certain point in the game where a ctd is contstanly reproducable. Until that time I'll keep my mouth shut over this matter.

Oooh that's a worry. Sounds like a memory leak somewhere. And maybe that's why I don't see it occuring on my dev machine with its 18Gb of RAM. mmm...

Miquel,

How much RAM have you on your dev machine? Would you like to take a crack at finding this memory leak?

Miquel,

I have emailed you ramses saved game.

ORIGINAL: Arjuna

Miquel,

I have emailed you ramses saved game.

I've got 8GB's as well. I'll take a look at that Dave [:)]

I've run Ramses' save (Autosave #2) till the end with no problems. See the screenshots below

And final situation

This was run on a Debug build of Command Ops (which has a bigger memory footprint that the Release versions distributed by Matrix). I'm now tracking with the Resource Monitor Command Ops process to see if there's any huge memory peak at some point during the execution.

This second run has gone one for five minutes now, and I see that it's using a very reasonable 100MBytes. Visual Studio 2010 takes up twice as much memory, in comparison.

Got to the end of a second playthrough (see screenshots for the final situation). Tracking CmdOps with the task manager I see that the memory footprint evolves in the following manner:

Start 98MB
D2 0600 101MB
D2 1600 107MB
D2 2200 110MB
D3 0700 111MB
D3 1600 112MB
End 113MB

This looks to me very reasonable, given the amount of stuff that has been going on in the game.

And the final situation

Ramses, if you have Win7 Pro, you should have the Resources Monitor application available from the Task Manager. Could you run the your save in your machine and just let it go at medium speed without further input - as I've done - and see if the size of the Working Set of the CmdOps process follows a similar profile as it does on my machine?

Thanks for looking into this matter Bletchley_Geek. I did precisely what you asked; as you can see the process does follow a very similar profile.

Start 88MB
D2 0600 91MB
D2 1600 94MB
D2 2200 95MB
D3 0700 96MB
D3 1600 100MB
End 101MB

I ran it with 5 min auto save on, Dave, as requested. No crashes. I've run it crash free for a while now. Another thing I changed around the same time, and have now changed back, was that I had selected a mouse option (available through the normal windows mouse control panel) whereby if I press CTRL a graphic appears on screen (concentric animated circles) showing me where the mouse pointer is. I never actually used this, but I noticed it was happening when I used CTRL to group units. It's possible that interfered. Not sure. Clearly, it pays to run MSDIAG and check what you have in your start section there. I have switched off everything I don't recognise or need. I assume Ramses has already done this, of course. It's par for the course that the thing that was sitting there probably causing a crash every five minutes - the back up drive driver - looked completely harmless and safe. Since the drive wasn't even connected I had assumed it was dormant. It clearly wasn't. Many harmless looking programs are probably like this - they do something every now and then.

After a couple of hours tinkering with this scenario, I finally have found a 'solution' to trigger a ctd.

1) load savegame
2) max out time
3) select the 21 Bty (SP) 55 Werger-rgt (next to gutmann hq)
4) select M for movement
5) hold shift key
6) place the first movement order between rumlange and stockem (see screendump) while holding shift.
7) place some more movement orders to the left with about 1 km intervals

I get a ctd 9 out of 10 times

Savegame sent.

Hey Ramses. Send me the savegame and let me try that also? Just curious.

peter.winship(at)skynet(point)be

Peter

And what do you mean by 'max out time'?

ORIGINAL: phoenix

Hey Ramses. Send me the savegame and let me try that also? Just curious.

peter.winship(at)skynet(point)be

Peter

And what do you mean by 'max out time'?

Savegame sent Phoenix. Max out time =

Yep!! Worked first time on fourth click. CTD as I clicked the fourth waypoint

ORIGINAL: phoenix

Yep!! Worked first time on fourth click. CTD as I clicked the fourth waypoint

Thanks Phoenix, it's 'good' to see that it is reproducable. Hopefully Arjuna can find out what is wrong.

ramses,

You are a jem, mate! [&o]

First off, the error I have jut detected had absolutely nothing to do with what you did in the interface. Rather it had to do with the movement of an inf gun platoon a few kms away. What was happening was that the platoon was moving in formation with its boss. The boss had two waypoints and had in fact moved past the first waypoint but for some reason had not removed it as it should. I can't tell why because it happened before the start. So the platoon for some reason, maybe it had been retreating, had to recalc its route. In doing so it creates an offset of its boss's route and seeds its waypoints by finding the closest index along the offset route that coresponds to the boss waypoints. Alas it it could not find an index that corresponded to the waypoint that should have been removed. However, it wasn't checking to see if the temporary found index was null or not, which it was, before adding it. Then when it tried to calc the route for the next leg it ended up with a null start and that caused the crash. I have fixed this now by doing a check and not seeding a waypoint. This means that it will ignore any waypoint passed by the boss already. So we should not have a repeat of this CTD.

However, I also got another assert when I tried to place a waypoint for the 21st Arty Bty in some woods. It should have automatically assessed that this could not move there and find a passable nearby loc. I'm going to investigate why this failed.

OK I ran through after the code change and noted that the cause is actually the boss who is forced to retreat and recalc his route without ditching the interim waypoint which he has in effect passed. mmm...need to think on that one. I'll be back.

ORIGINAL: Ramses

Thanks for looking into this matter Bletchley_Geek. I did precisely what you asked; as you can see the process does follow a very similar profile.

Start 88MB
D2 0600 91MB
D2 1600 94MB
D2 2200 95MB
D3 0700 96MB
D3 1600 100MB
End 101MB

Cool Ramses [:)] As I imagined, the Debug build footprint is about a 25% greater than the Release version.

Arjuna,

It's good to see that you found some bugs in the savegame and that I haven't been wasting your time for nothing. I have some earlier saves prior to the one I sent yesterday; if they could be of any value I will be happy to mail them.

Finally I would like to express my appreciation for the support over here; it is truly unrivaled...

Thanks,

Ramses