HTTR & Greek Scenarios: Clarification Please

[rmp090946]

I own the additional expansion scenarios referenced above.

It's my understanding that, at this point, these scenarios have not yet been updated to be compatible with Command OPS: BftBulge version 4.6.272. Am I correct?

Thanks,

Bob

[Werewolf13]

ORIGINAL: rmp090946

I own the additional expansion scenarios referenced above.

It's my understanding that, at this point, these scenarios have not yet been updated to be compatible with Command OPS: BftBulge version 4.6.272. Am I correct?

Thanks,

Bob

Good question though one wonders why the HTTR and Greece scenarios would require any updating?

Anxiously awaiting an answer to this because I've installed the just published 272 build but have yet to try it out. Since I am currently mostly playing the HTTR scenarios...

[parmenio]

I think it relates to not having updated the map cache, so load times can be loooooong... in fact long enough for you to give up.

There was a thread on this (but I can't find it). Basically open up the map in the Map Editor and save it again and it should then load ok.

Edit: Actually I don't think it's the cache because the file doesn't get updated... it appears to be the map file itself that gets converted to the new build. The BTFB maps seem to get supplied updated with the beta patches - the HTTR and Greek ones need manually doing.

[jimcarravall]

ORIGINAL: rmp090946

I own the additional expansion scenarios referenced above.

It's my understanding that, at this point, these scenarios have not yet been updated to be compatible with Command OPS: BftBulge version 4.6.272. Am I correct?

Thanks,

Bob

If you experience what you consider a long lag, there is a background calculation in process to calculate map effects.

In some instances (fire effects, observation, route selection, among them) the patch has reduced the distances between sampling points for terrain effects calculations.

The more points that have to be evaluated on the more refined grid, the longer it takes to load a map so the scenario can start.

Such is the nature of changing evaluation criteria for determining sighting and combat fire effectiveness on the digital maps.

[Arjuna]

When we provide a full official patch as opposed to a public beta patch it included all updated data for all expansion packs. For a public beta patch it only includes updated BFTB data. The reason for that is purely time. It can take a quite a while to convert all the data. Now during the beta process if we change the data format of a class then we have to convert all related data. Sometimes we can put out a beta build where there is no data format changes and all the scenarios from all expansion packs will work fine. But I can't guarantee that.
 
The thing about this public beta process is rapid turnaround. It's iterative and not without the odd pitfall. So if you don't want to be affected then stick to the official patches.
 
 

[Werewolf13]

So installing 272 was probably a bad idea since I'm currently playing the HTTR scenarios and now cannot do it?

[Arjuna]

Just roll back to the last full patch.

[Arjuna]

ORIGINAL: Arjuna

Just roll back to the last full patch. Or you can wait for the next full patch which if all goes well will be out soon.

[navwarcol]

Or you can put them in the scenario editor. The load times for that can be long, but not impossibly so, mine was about 15 minutes.

[rickier65]

ORIGINAL: Werewolf1326

So installing 272 was probably a bad idea since I'm currently playing the HTTR scenarios and now cannot do it?

I was able to play them .273. I think it gave me a warning about taking a while, but it didn't take a while. I'm playing with .273, I didn't try with the .272. I guess to be accurate, I didnt actually play the HTTR scenarios, I just loaded a couple to check on something.

Rick

[midgard30]

Sorry to bring that up again, as it has been discussed many times, but I've just installed the latest beta patch and wanted to be sure that everything was normal.

I tried to load the HTTR scenario "From the Muese to the Rhine" with version .276 and took about 7 minutes. After pressing "Begin", the game crashed. So I loaded the scenario in the ScenMaker which also took 7 minutes and saved it. Then, I loaded the scenario in CO and took again 7 minutes but worked.

So I conclude that the long loading time is normal? Is there something to do to improve this?
Thanks

[Phoenix100]

.276 isn't the patch Dave meant, macob. That's just an interim beta. With .276 you're better off doing the fix in the Mapmaker, mentioned above, which works fine, otherwise you will suffer very long load times with HTTR and Greek maps. BUT, Dave has said that he put the FINAL, and official, patch in with Matrix over a week ago, and all the data is converted in that patch, so when matrix get round to giving us it you will be fine. You could pester Matrix for that patch, maybe? [;)] We're just waiting for them to put it up.

Peter

[jimcarravall]

ORIGINAL: macob30

Sorry to bring that up again, as it has been discussed many times, but I've just installed the latest beta patch and wanted to be sure that everything was normal.

I tried to load the HTTR scenario "From the Muese to the Rhine" with version .276 and took about 7 minutes. After pressing "Begin", the game crashed. So I loaded the scenario in the ScenMaker which also took 7 minutes and saved it. Then, I loaded the scenario in CO and took again 7 minutes but worked.

So I conclude that the long loading time is normal? Is there something to do to improve this?
Thanks

The lag is caused by the software interface recompiling the terrain tables.

As Phoenix said, it can be eliminated by opening the map in MapMaker and saving the map back to the original map filename "XYZ.cop." This activity allows the game to evaluate terrain effects on a smaller sample grid than the original compiled HTTR and Greek Pack maps had built into them.

Particularly for larger files, it may be a worthwhile task to build a map cache (XYZ.cop.cache) once MapMaker has finished opening the original map file.

The cache contains embedded "look up" calculations more frequently used by the game engine so the engine doesn't have to take time to make those calculations during game play.

The Beta patches are released with only the BftB maps recompiled to the more refined terrain sampling grid.

[midgard30]

Thanks to both of you.

Obviously I misunderstood information read in a couple of threads, and used ScenMaker instead of MapMaker. And just to be sure that I really really understood correctly this time, there's no need to convert scenarios, only maps, or is it better to convert both?

I converted Maas-Rein with MapMaker and generated a map cache. It works fine and loading time is back to normal (very quick).

BUT, Dave has said that he put the FINAL, and official, patch in with Matrix over a week ago

Happy to read that! I'm waiting for the final patch for a long time now, Since I didn't know when it would be out and wanted to play with the new patch and try few HTTR scenarios, I decided to convert some. But since the patch is now in Matrix's hands, I'll stick to those already converted. Anyway, loading time is short for small ones.

You could pester Matrix for that patch, maybe? We're just waiting for them to put it up.

I can do that: Hey Matrix! What are you waiting for? Hurry up, we want the patch! (big [;)])

[jimcarravall]

ORIGINAL: macob30

Thanks to both of you.

Obviously I misunderstood information read in a couple of threads, and used ScenMaker instead of MapMaker. And just to be sure that I really really understood correctly this time, there's no need to convert scenarios, only maps, or is it better to convert both?

I converted Maas-Rein with MapMaker and generated a map cache. It works fine and loading time is back to normal (very quick).

Scenarios do not need to be recompiled.

SceneMaker basically points the command ops engine to user selected map data (created and compiled in MapMaker) and combat force data (created and compiled in the Estab Editor) used to model scenario specific combat criteria. Resaving SceneMaker settings does not change the original map (.cop / .cop.cache) or combat force data (.coe) files.

[Arjuna]

That's not strictly true Jim. The scenario file itself contains data and has it's own format. If this format changes then a conversion is required. In some cases, such as with the Med and Greek scenarios the format has changed. A full conversion will convert the map, estab and scenario files.

[jimcarravall]

ORIGINAL: Arjuna

That's not strictly true Jim. The scenario file itself contains data and has it's own format. If this format changes then a conversion is required. In some cases, such as with the Med and Greek scenarios the format has changed. A full conversion will convert the map, estab and scenario files.

Well, you'd know

I recall trying to resave the HttR Scenario files after waiting for the map to convert, but it didn't seem to result in the map loading any quicker the next time I opened that scenario. That's when I resorted to recompiling the map with MapMaker.

[Arjuna]

Jim,
 
Yes I do! [;)]
 
You are correct in that just converting the scenario is not enough. You need to convert the map and estabs too.

[midgard30]

So all in all, there's no need to save a scenario, unless it is needed. Or the opposite. [:)]

[jimcarravall]

ORIGINAL: macob30

So all in all, there's no need to save a scenario, unless it is needed. Or the opposite. [:)]

Now that Dave has indicated there may be CO patches which impact a scenario file, I guess it can't hurt.

In the instance of the most recent patch, I have to open the scenario which posts a message indicating it may take some time to load a map inside SceneMaker to identify the map file name which needs to be recompiled using MapMaker.

My new habit will be to save the scenario file name after I identify the map file name as a "just in case."

Bottom line is that saving a file in SceneMaker does not correct any issues with Maps or Estabs that may trigger a message indicating there is a delay opening a scenario.

By my experience most often the "be patient" message points to a map calculation as a cause for the delay.