Can't play scenario.

[Predator145]

Does anyone ever have the problem of loading a scenario when it's at 100% and then the game just exits?

 

[Vuldacon]

Does anyone ever have the problem of loading a scenario when it's at 100% and then the game just exits?

No but that indicates that there is something missing or a difference in the Scenario that you do not have. Could be simple to correct but finding the reason is the first problem to solve.

You could state the Name of the Scenario for starters.
Ask someone that can open the Game questions about there Operating System and what type of installation they use for the CIV Game such as Steam, GOG, CDs

 

[Predator145]

No but that indicates that there is something missing or a difference in the Scenario that you do not have. Could be simple to correct but finding the reason is the first problem to solve.

You could state the Name of the Scenario for starters.
Ask someone that can open the Game questions about there Operating System and what type of installation they use for the CIV Game such as Steam, GOG, CDs

The scenario is my own created mod. It's modded with the Quintillus editor where I pushed the limits with things like assigning ground units the air bombard AI strat, used many king units and such. When I tested these on a smaller scale in the WWII scenario, they all worked. I can't figure out what causes the issue.

The unit addition is what's vast with all the flavor stuff that I'd like to salvage if possible. Is there anyway to copy paste them into another scenario?

Game version is GOG from Steam.

 

[Vuldacon]

Too many unknown possibilities causing the problem. Only You know what Units worked in the WWII Scenario.

You need to find what is causing the problem...Trouble Shoot what you have. Think about what you know.
Save your original Biq then Experiment by removing Units and Buildings that are in the Game from the Start. Do this One at a time as you test if the Game opens.

 

[Civinator]

It's modded with the Quintillus editor where I pushed the limits

Predator145, this can happen when pushing the Quintillus editor to the limits - especially when allowing deep cuts into the safety levels of that editor.

Game version is GOG from Steam.

Predator145, this shows that you should take a little break and than reflect, where in your mod you have set the safety level to 'None' or 'minimal' and than correct these settings to the levels at least 'exploratory' or better and than try to restart your biq.

I don´t think, that the king units will be a big problem (when it is not January 8th). CCM is running with tons of king units without any problems.

 

[Predator145]

Safety level has been on "safe" all the time.

So I've removed all the added techs, resources and buildings and adjusted the terrain back to familiar settings. The only foreign elements to stock game are the units. Yet I still can't run the game.

Here's the biq. Can someone adjust the scenario property to stock game and try running it?

 

[Civinator]

Predator145, when your Dummy biq is opened with Firaxis editor 1.00 there are completely crazy values for your terrain settings. Allowed are only settings up to 25, but here you run into the chaos. The terrain civilopedia entries are missing, too. Additionally you have two terrain settings without any access and LM terrain with absolute crazy spellings.

May be you should adjust all terrain values to normal values with the standard Firaxis editor and than have another look to the game. With the Quintillus editor you don´t see these crazy values, but you have that freeze short before the 100 % are graphically completely reached.

 

[Civinator]

I imported the terrain values from CCM and had to rename the civilopedia entry of one tech, that was not covered by the CCM pediaicons file and than I was able to start your Dummy 2 biq. May be you have to rename the entry of that tech back if you haven´t installed CCM 2.50 as your expanded C3C mainfiles.

 

[Predator145]

I imported the terrain values from CCM and had to rename the civilopedia entry of one tech, that was not covered by the CCM pediaicons file and than I was able to start your Dummy 2 biq. May be you have to rename the entry of that tech back if you haven´t installed CCM 2.50 as your expanded C3C mainfiles.

Thank you so much for helping me figure out the reason! I can run the game now.

How the heck did those values even appear in the Firaxis Editor ?!!! I've never touched that part. My terrain editing happened exclusively on the Quintillus one, which didn't show any of that. After fixing them on the other biq saves I could run them as well.

 

[Vuldacon]

Predator`45... Strange phenomenon with the Biq but Glad you have your Game back where you can play it ... I am certain Civinator as well as Quintillus are very interested in finding the reason for the situation.

 

[Quintillus]

I did a preliminary investigation, using the BIQC functionality in the editor. The notes here are more of a scratchpad than an answer; I'm saving them to build on later.

While it showed that there are some differences in areas such as BLDG and GOVT compared to a "vanilla" BIQ, before the unit changes, it does look like the TERR area is the area of concern. The diff results for that section begin:

--> Terr <--Standard.biq | Dummy Mod2.biq

name: Desert
DataLength: 233 | 237
NumPossibleResources: 26 | 16
FoodBonus: 1 | 2
AllowAirfields: 1 | 0
AllowOutposts: 1 | 0
AllowRadarTowers: 1 | 0
LandmarkEnabled: 1 | 0
LandmarkFoodBonus: 1 | 2

The key difference that I suspect is resulting in the crazy numbers in Firaxis's editor is the DataLength difference. My editor does its best to ignore that field (other than updating it as necessary, for sections where it is modified); Firaxis's editor follows it religiously. Consequently, any case where it becomes an improper length can result in data corruption, and the sort of strange issue you have run into.

As evidence that this is the problem, you can note that the Firaxis editor (I have version 1.03, which is somewhat newer than Civinator has) displays the Desert terrain at least mostly correct (aside from the Landmark Civilopedia entry), but as soon as you switch to Plains, the second terrain, you have values that are nonsensical. This is consistent with a data length problem.

The question then becomes, how did the data length become 237 instead of 233? I'm going to have to take a look at that when it isn't super late. Looking through the code, it looks like the only places my editor updates that are when it reads a BIQ file. Although, the NumPossibleResources field should at some point have an impact on DataLength, which makes me wonder if I am missing something. Still, the overall number of resources is the same between Standard.biq and Dummy Mod2.biq, and the number possible for desert is lower in Dummy Mod2.biq, so nothing jumps out as explaining why DataLength would be higher.

Comparing the non-working BIQ and the one Civinator fixed in a hex editor, I see both have a terrain data length of 237, but Civinator's has more data on the "possible resources (binary)" area - the non-working one has two bytes for 16 resources, and Civinator's has 8 bytes for 59 resources. The bytes per resources amount passes a non-rigorous validation in my mind, but those additional six bytes should affect the data length. The non-working one has a manually measured length of 0xEB per resource, or 235, whereas Civinator's has a manually measured length of 0xF1, or 241. Neither of those is 237, but data length doesn't necessarily include the length necessary for the data length variable, and Civinator's is a version 12.06 BIQ, instead of 12.08, which may also be a factor. Still, the fact that Civinator's fix produced a BIQ where the data length variable remained the same, but the actual data length increased by six, points to an inconsistency.

Meanwhile, the Standard.biq file says it has a DataLength of 233, and actually has one of 237. This is consistent with the Civ practice of the real data length not including the 4 bytes that report what the data length is.

Conclusions:

• An investigation into how to reproduce this should likely focus on adding, and perhaps removing, resources. I suspect that this arose due to a changing number of resources at some point, and am mildly suspicious that I don't see code in my editor to increase the dataLength as the number of resources increases (although something increased that number).
• Even among reported good BIQs, we see some inconsistencies; why does Standard.biq has a length 4 less than reality, but Civinator's fix match reality? Data length has always been one of the more confusing parts of the BIQ, but this still manages to be a top 5 case for "confusing data length problems".

I will likely revisit this when less tired, with a focus on trying to establish how to reproduce this problem, and going from there to how to prevent it in the future.

 

[Civinator]

Quintillus, thank you very much for your last post. For helping to solve the riddle about the crazy terrain values, here are some additional facts about my use of the Firaxis editor 1.00:

I have both Firaxis editors (1.00 and 1.03) but I prefer using editor 1.00 (when not using your great editor), as in Firaxis editor 1.03 the scientific great leader cannot be set to be working in the game. In other words: Firaxis editor 1.03 is bugged. Editor 1.00 is the original C3C editor (before both parts of the C3C patch) when C3C was released. Firaxis editor 1.00 still can be downloaded here: https://www.civforum.de/showthread....Modding-Ecke&p=2326584&viewfull=1#post2326584

I used the Firaxis editor 1.00 to look for the problem in the 'dummy biq', as here your editor didn´t help. May be it is important, that I have not fixed the dummy biq by hexediting, but by simply using Firaxis editor 1.00 and setting the crazy terrain values to the normal C3C values - and than the dummy biq did run.

 

[Predator145]

Yes, I did add a lot of resources in an attempt to counter act the removal of railroads. But since Flintlock's patch I reinstated rails and removed them. I must have added 4 extra copies for each bonus food resource.