CC5 Stalingrad VL Bug
Select messages from
 # through # Forum FAQ
[/[Print]\]

Close Combat Series -> Modding Workshop
#1: CC5 Stalingrad VL Bug Author: mooxe,  PostPosted: Fri Mar 16, 2018 12:20 am
    —
Tsarista Woods is on the Western edge of the strategic map. An older version of Stalingrad had a one way VL going from Stalingradskii to Tsarista Woods. I changed this so VLs on both maps worked.

The next battle up is at Tsarista Woods and the campaign crashes to desktop every time. We are a few days into the campaign and have been battling on the map every turn, the problem has only just come up. There has been no change of battle groups in the last few days. We are on the afternoon turn, no reinforcements are trying to deploy.

Image below is the error BED9 shows when I load up the twoods.btd file.



I edited the VL to a 50 value and it also crashes out the game. To continue playing the campaign I had to make the VL a normal VL with a value of -52. Removing it completely enables us to continue as well.

Adding a -2 VL or changing any current VL causes a lockup or crash to desktop.

Opytnaya Stantia is setup as the deploy VL but new BGs never spawn here, they always spawn in the upper left on the exit to Stalingradskii.

Will editing out the VL as a deploy VL have any after effects on the GC?

Can anyone explain whats wrong?
#2: Re: CC5 Stalingrad VL Bug Author: mick_xe5,  PostPosted: Fri Mar 16, 2018 6:35 pm
    —
Changing the oneway VL going from Stalingradskii to Tsarista Woods shouldnt pose an issue as long as you did it prior to starting your camp. My CC5 v1.2 Stalingrad mod already had this VL as two-way, possibly thanks to you.

The mis-coding of the To Opytnaya Stansia deploy (entry) VL as 100 points rather than 50 is causing the game to deploy arriving BGs on the To Stalingradskii VL. When a VL is mis-coded like this the game selects an alternate entry VL on, or closest to the 'home' side of the map for that force. In stock CC5, if you change the Tare Green VL to 100 points youll see US BGs arriving  on that map also use an alternate entry VL. This mechanic is similar to how the game selects an entry VL for sarriving BGs in a custom scenario.

The save file tracks VL control separately from map control. The order in which VLs are listed in the BTD is also the order in which they are tracked. Editing BTD files during an op/camp can cause a mismatch between the map control tracking and the VL tracking in the save. eg. after an edit the save file map control tracking may specify the Allies control a megatile occupied by a VL but the VL control tracking says its an Axis VL.

Although it doesnt seem to matter, stock CC5 BTDs list VLs in a particular order - starting top left on the map, down the leftmost column of megatiles, then from the topo of the column immedaitely to the right to the bottom of that megatile column, and so forth to the bottom right corner of the map. I tend to think there was a purpose for doing it this way but it may just be that Atomic's BTD tool autosorted the VL list that way. OTOH, Mafi's BTD lets you list VLs in any order.

Rather than delete the To Opytnaya Stansia VL and risk a VL track/map control mismatch, I'd suggest just changing it to a normal -52 VL. Another possible issue to deleting a VL is that the save file may track cumulative VL scores for each player. If so then deleting one would alter one player's score and/or the total VL points available in the scenario.

I have no answer as to why the game chose that turn to crash apparently due to that mis-coded VL. I'd be interested in having a look at your save file.
#3: Re: CC5 Stalingrad VL Bug Author: mooxe,  PostPosted: Fri Mar 16, 2018 11:38 pm
    —
Thank you. I will edit it to a 100 -52 point VL.
#4: Re: CC5 Stalingrad VL Bug Author: mooxe,  PostPosted: Sat Mar 17, 2018 1:08 am
    —
Actually its still crashing if I make the VL a -52 value. Only thing working is deleting it.

Stal1.2VLbug.gc
 Description:

Download
 Filename:  Stal1.2VLbug.gc
 Filesize:  1.53 MB
 Downloaded:  294 Time(s)
Close Combat Series -> Modding Workshop


output generated using printer-friendly topic mod. All times are GMT

Page 1 of 1