help desk requested post here for developer

help desk requested post here for developer (Full Version)

All Forums >> [New Releases from Matrix Games] >> The Operational Art of War IV >> Tech Support

Message

fastfrank -> help desk requested post here for developer (6/27/2019 7:22:57 PM)
Now running latest TOAW IV baseline from member's download page. Ran France 1944 Cobra scenario without any edits (release version). Ran with PO running game, with saves at start of each turn for each side. Game vanished on Allied turn 16 at about combat round 6. Has now blown up 7 times out of 7. Repeatable. Tried to get save just prior to blowup. Finally got save close enough that when I tried runninhg again, game ran to normal conclusion, Made me think maybe this is a timing issue with my Intel multiprocessor chip??? Ran save file with OPart slow but blew up as before. To recreate, run save file with Play/Computer Player Western Allies. On my PC, dies at about 14 minutes during combat turn 6 or later. Saves of all prior turns available if useful.

fastfrank -> RE: help desk requested post here for developer (6/27/2019 7:24:39 PM)
save file

larryfulkerson -> RE: help desk requested post here for developer (6/27/2019 7:25:29 PM)
quote: latest TOAW IV baseline does this mean you haven't applied any of the released patches?

larryfulkerson -> RE: help desk requested post here for developer (6/27/2019 7:32:14 PM)
I downloaded your save game and right now the computer is playing the computer and it's running just fine. I have applied both patches to the game engine. Maybe it's crashing because you're running an old version of the game engine?

fastfrank -> RE: help desk requested post here for developer (6/27/2019 7:47:03 PM)
deleted TOAW IV, then downloaded/installed 4.1.0.20 and then 4.1.0.21

fastfrank -> RE: help desk requested post here for developer (6/27/2019 7:54:01 PM)
which patches?

larryfulkerson -> RE: help desk requested post here for developer (6/27/2019 7:58:22 PM)
Here's a link to this web page: http://www.matrixgames.com/forums/tt.asp?forumid=1514 [image]local://upfiles/16287/58FEDBB10FF04EF49DE9471D93558052.jpg[/image]

fastfrank -> RE: help desk requested post here for developer (6/27/2019 8:16:07 PM)
somewhere I saw instructions to delete TOAW IV, then install 4.1.0.20 as a complete new program and then install 4.1.0.21 as a patch....

Zovs -> RE: help desk requested post here for developer (6/28/2019 1:33:17 AM)
I don't think that is correct, you'll need to install the base game (mine so happened to be the installer with 4.1.0.20 IIANM) and then run the .21 patch.

Lobster -> RE: help desk requested post here for developer (6/28/2019 3:32:43 AM)
quote: ORIGINAL: fastfrank somewhere I saw instructions to delete TOAW IV, then install 4.1.0.20 as a complete new program and then install 4.1.0.21 as a patch.... If you had a previous version of TOAWIV (pre .20) then you needed to do a complete uninstall. If you are making a new install you naturally would not need to uninstall anything.

sPzAbt653 -> RE: help desk requested post here for developer (6/28/2019 5:40:33 AM)
Version 4.1.0.20 Available! [12/6/2018] PLEASE NOTE: we have discovered an issue with this build and are presently working on a fix. You should not install this in the meantime. If you have already done so, please see HEREfor a manual fix while we work on the patch. http://www.matrixgames.com/forums/tm.asp?m=4564492 So WHY is this version still available for download? Six months after the fact? [image]local://upfiles/24850/DA3B84E00E0B4031AFE234BBC44F38F0.jpg[/image]

larryfulkerson -> RE: help desk requested post here for developer (6/28/2019 5:42:10 AM)
quote: So WHY is this version still available for download? Six months after the fact? +1

Zovs -> RE: help desk requested post here for developer (6/28/2019 8:56:45 AM)
I did not think there was any issue with .20 but with the .22 patch and the .21 was the only one that worked so the .22 was pulled. Maybe we need a new .23 to clear it up but I heard of a .30 patch, and there may also be a new TOAW V, so it’s confusing and disorienting with the numbers but it is safe with the .21 patch just avoid the editor bug that CTD and your good.

Lobster -> RE: help desk requested post here for developer (6/28/2019 11:52:27 AM)
quote: ORIGINAL: Zovs I did not think there was any issue with .20 but with the .22 patch and the .21 was the only one that worked so the .22 was pulled. Maybe we need a new .23 to clear it up but I heard of a .30 patch, and there may also be a new TOAW V, so it’s confusing and disorienting with the numbers but it is safe with the .21 patch just avoid the editor bug that CTD and your good. There is no TOAWV. .30 is not a patch and shouldn't even be mentioned here by a tester. It just sows more confusion. As far as I know all there are is .20 and .21 and nothing more. It seems we have become orphans once again. [:D]

fastfrank -> RE: help desk requested post here for developer (6/28/2019 11:07:26 PM)
I would not be surprised if it will run fine on any machine configuration except mine. Since on the 8th run I stopped to save just before the fatal point and it then ran to end of tern makes me suspect the Intel multi-processor might be experiencing a timing conflict and the pause might have permitted a timing conflict to resolve???? Maybe. Any idea why the help desk said post on the forum for "the developer" to see? Old staff officer saying "an action passed is an action completed"?

Shadrach -> RE: help desk requested post here for developer (6/29/2019 10:07:26 AM)
Catch 22 I guess... I've long suspected Matrix Support to be staffed by ex-military types more concerned with following procedure than solving actual user problems... [8\|] And the developer has gone AWOL, although I suspect he's reading these forums - he just realised that actually interacting with users just takes up too much time. Fair enough. You are a customer, and as long as Matrix sells this product you are entitled to support. I would keep pestering support until they give you a concrete solution or at the very least a confirmation that the developer knows about the issue. If the application is "vanishing" (i.e. crashing) there should be crash dumps available. For Windows 10 these are usually located in the folder: c:\Users\<username>\AppData\Local\CrashDumps These dumps can give support clues on what might be causing the crashes. Any halfway decent support organisation will have the tools needed to analyse these dumps. Attach a couple of them to your support ticket.

larryfulkerson -> RE: help desk requested post here for developer (6/29/2019 10:50:31 AM)
Actually the crashlog.txt file is found in the root directory of the game. [image]local://upfiles/16287/37B7B7870C41495E9BD6CEA3A7D06F7B.jpg[/image]

Shadrach -> RE: help desk requested post here for developer (6/29/2019 11:33:23 AM)
Well, the crashlog.txt would definitely be useful for support to have a look at. But it's not the same as a crash dump, which is a binary file used for analysing application crashes. You need special tools to get data from a dump, usually something like WinDbg. And you need to actually know the application and the code, so this is usually something only the developer (or a skilled support tech) can do. I'm not sure though, that TOAW4 creates a dump when crashing...

Shadrach -> RE: help desk requested post here for developer (6/29/2019 12:36:40 PM)
I suspect a memory leak. I actually was able to reproduce the crash here running a couple of turns of the provided save, with AI playing both sides. During the run I was monitoring CPU and memory usage for TOAW4. Memory starts out at about 400MB at the start of the Allied turn, then slowly grows to 1.5GB during the turn. There appears to be no attempt by the game to do some housekeeping to clear memory. Memory is only cleared at the start of a new turn. [image]https://i.imgur.com/vF2qnGV.png[/image] This is during AI turns. Not sure if memory grows during a human player's turn or if it's cleared after each round. It crashes during the Allies' turn because there are more units to move. I would also suspect this is the cause of many crashes people are seeing on the bigger scenarios. The limit for a 32-bit process is about 2GB unless it's Large Address Aware. It might also be a lot less before a crash, for reasons like virtual memory management. No crash dump is generated in Windows, but attaching crashLog.txt, even though I doubt it will shed any more light on it.

fastfrank -> RE: help desk requested post here for developer (6/30/2019 4:36:59 AM)
Thanks for the most useful input to date. I tested my hypothesis that a multi-processer timing conflict was at the root of this. Ran turn 16 using the move PO button and then the execute all combats button to create pause times. Crashed on combat round 6. Tried reproducing your research, had to use task manager/processes screen, couldn't figure out how to get your graph. Had 4.6 GB used before launching TOAW, 5.5GB after launch, 6.1 before crash out of 15.9GB available. So don't know if TOAW eventually exhausts available memory or trashed what it is using.... I appreciate your help, thanks. Will reply to the help desk and ask if the developer has looked at this.

Shadrach -> RE: help desk requested post here for developer (6/30/2019 10:15:58 AM)
That's good - I'm pretty sure a memory leak is what's going on here. But it will probably take a long time to get it fixed with the rate of patches we're seeing (about six months since last). In the meantime, not sure what to do to avoid the crashes. The shot I posted is from the tool "Process Explorer" and you can download it here: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer It's basically a "Task Manager on steroids" and allows you to see details of every process in a lot of detail. On multi-processor: The game is multi-threaded, but by default the game logic itself runs in a single thread on a single processor/core. The audio playback runs in a couple more threads. You will see this in Process Explorer under the "threads" view of the process. There is actually a flag in "Opart 4.ini", by default false: multicpu=N I've tried setting this to 'Y' - and it does spread the main game load over several cores, but it seems to have no noticeable effect on game speed when I've tested it, so I've kept it to 'N'. Best of luck with support - but don't keep your fingers crossed they will come up with anything soon [:D]

Lobster -> RE: help desk requested post here for developer (6/30/2019 3:27:29 PM)
The scenario did crash towards the end of the turn during combat planning. Computer vs computer. Like watching grass grow or paint dry. Has someone modified this scenario from the original since TOAWIV? Forgot to say, my system's memory was no where near maxed out. And yes, fixing stuff is glacial. [:(] [image]local://upfiles/45799/144D7F42D0204320B8C6D7377A9E4BA2.jpg[/image]

Shadrach -> RE: help desk requested post here for developer (6/30/2019 4:46:39 PM)
Lobster; it's hard to tell from that image how much memory the TOAW process itself was taking up. It's strange that you don't see any increase in memory usage. Maybe the graph just isn't detailed enough, don't know. Try the same with Process Explorer (if you're interested in these things [;)] ), and double-click "Opart 4.exe" when it runs, then open the Performance Graph tab. Anyway, I did some more digging, since I wanted to find out if my theory of audio playback was causing the leak. And apparently not - just moving units around the map doesn't increase memory much, as I would expect if the leak was there. However - and this is really interesting - just moving the map increases memory by a massive amount! Especially around the heavily urbanised areas in the north, around Bruxelles - Gelsenkirchen, the game will become really sluggish and memory use will increase in leaps and bounds. Once memory reaches short of 1.9GB, the game will hang and crash. [image]local://upfiles/4523/1539B2D522B74973AEEB268166ED24A9.jpg[/image] Of course, as the player moves around, or during the AI play, the map will move and memory will slowly build. I tested with a couple of other huge scenarios, D21, FITE2, and saw nothing. Memory stayed a sane 3-400MB even during a full turn of FITE2. I tried with another similar scenario, "France 1944 D-Day", and the same happens there, as the terrain is the same. So there is something up with how the terrain tiles are modelled in that scenario around that area.

Lobster -> RE: help desk requested post here for developer (6/30/2019 7:10:32 PM)
Yes, I suspected it was the scenario otherwise there would have been many more crashes reported. Another one that someone has modified and causes crashes is here: http://www.matrixgames.com/forums/tm.asp?m=4601852 Next War 1979 - Expanded (Beta 1.0) I wouldn't be surprised if there are other TOAWIII scenarios that have been 'converted' that also crash the game. Because of the changes in TOAW between 3 and 4 not everything works as it once did. Simply saving an older scenario in the newer version will not guarantee success. BTW, memory usage did increase about 6% as more combats were planned until the game crashed. But with all of the units and combats that isn't surprising. I wonder if France 1944 D-Day will crash.

Shadrach -> RE: help desk requested post here for developer (6/30/2019 10:28:01 PM)
France 1944 D-Day will crash, it's pretty much assured. Once memory increases like that and never gets collected, it's only a matter of time. Well, depends a bit on how much the player moves the map around I guess, and how much AI movement will move the map around as well during its turn. I tested the "Next War 1979 - Expanded (Beta 1.0)" scenario, the same thing happens there. Some other observations: - Doesn't appear to happen in the editor. - Doesn't appear to happen in the tiny/ultra tiny map sizes. - Also happens in 3D view, which is weird... For all I know, it happens on all scenarios, and that's actually more likely, it's just that some scenarios have a bigger concentration of whatever causes the memory to increase...

fastfrank -> RE: help desk requested post here for developer (7/1/2019 5:24:51 AM)
For 3 years I thought I was the only player having this problem. Thought it was specific to my PC configuration. Smart people have said the first step to solving a problem is identifying/validating the problem. Thank you very much. Although I was a programmer/system analyst in the 60's and early 70's, that was before we even had operating systems. So for now I will download the tool you used, and try to study tactics that release memory and permit play while awaiting a fix, i.e. save & exit game mid-term or mid-round, or when memory consumption nears a TBD threshold. Thanks again.

Shadrach -> RE: help desk requested post here for developer (7/1/2019 9:17:59 AM)
No worries, happy to have been of some help - I actually like doing digging like this, feels like being a detective [8D] And hey, computers haven't really changed that much since the 70's. The basic concepts are the same, you have CPU, Memory and I/O. Of course, back then memory was a very expensive resource and programmers learned to stay within very small limits. These days memory is cheap and plentiful and it seems programmers have lost the old skills of memory management. Even the browser tab I have this page open on takes a whopping 43MB of memory - for ONE page [8\|] Let us know if you hear anything at all from support - it will be interesting to know what they say!

fastfrank -> RE: help desk requested post here for developer (7/6/2019 4:29:13 AM)
Ran Turn 1-16 again to gather what information might be useful. This is really "black box analysis" without any tools or insight of the internals. Nonetheless kept Task Manager/Performance open to track available memory as well as Performance Monitor to track private bytes consumption. What I found: A. Consumed private bytes dropped back to ~300-400MB at start of each player Turn. Growth was slow but steady during Turn. B. Although consumed private bytes looked like (on the System Monitor graph) to be approaching the ceiling many times, Win10 increased allocation each time. The memory consumption chart here can be deceiving since the vertical axis is apparently computed automatically, and as the size of the allocated private bytes is increased, the entire graph is immediately rescaled. See, e.g. the Allied progression in Turn 16 from 809MB to 827MB, from 966 to 989MB, Perhaps significant is the available memory during Turn 16 only decreased from 11GB to 10.3GB at program crash. Not sure memory leak can be confirmed as cause of the crash. C. Since 3 of us have now had crashes with the identical scenario, chances of this being caused by a specific PC configuration, considering how many variations are possible, must be most unlikely. D. When I saved this game run for analysis, I set PO random seed to -0, to eliminate any stochastic variability during the analysis. TOAW IV blew up 7 of 7 times identically before I started the thread. Nonetheless, last night while gathering my data, TOAW completed Turn 16 and continued onwards. [I was tempted to add an exclamation mark to the prior sentence or even one of those omicons, but recovered my senses.] Nonetheless, either this software is subject to the Heisenberg Uncertainty Principle, or we don't fully understand the system design or I've had too much Cabernet, but when software produces different results while repeating then the end of the world is not far off.

Shadrach -> RE: help desk requested post here for developer (7/6/2019 2:40:34 PM)
There's definitely a memory leak if memory keeps increasing during gameplay, with no attempt to clean it up before the memory reaches the 32-bit limit. Like I said, I'm able to make it crash within a couple of minutes by just running the map around. The memory 'ceiling' shown in Process Explorer is just computed to make the graph look better and it will scale as it increases. The limit of a 32-bit application running under Windows is 2GB, and it apparently triggers a crash even before it hits the limit. https://docs.microsoft.com/en-gb/windows/win32/memory/memory-limits-for-windows-releases https://superuser.com/questions/1163749/why-do-32-bit-processes-have-a-2-gb-ram-limit/1163939#1163939 I made a quick video showing how quick it is: https://drive.google.com/open?id=1xmYj7sJOIYHrTYiXlk89QPP9x37fsrQU At this point no crash dump was generated, but I've had them generated before. That being said, you might sometimes get 'lucky' like you said in point D. Maybe there's not enough movement of the map during the turns to make it crash, and at the start of a new turn, the memory is cleared. And like you said, this is "black box analysis". The only ones who can give an answer at this point is the developer or support, by recreating the crash on their side, obtaining crash dumps and analysing them for the cause of the crash. At the very least, an acknowledgement from them that "we are aware of the issue" would be good.

fastfrank -> RE: help desk requested post here for developer (7/6/2019 5:18:03 PM)
he is reply from helpdesk Hi fastfrank, The game producer confirmed me, that he have sent an email to the game developer asking him to reply in that thread. Kind Regards, Paulo Costa The Slitherine Group

Page: [1] 2 3 next > >>

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

0.7929688