CMO Public Beta - Build 1263.1

[Twistedpretzel]

So many quality of life improvements lately, much appreciated.

[bsq]

- ARH weapons fired by such systems (e.g. 9M96, 40N6, PAC-3 MSE etc.) are exempt from this restriction as they do not need continuous illumination from the launch facility.

So close, but not quite right. The datalink T/R elements are still on the live side of the array and are directional not omni, so they will still need to be pointing down range during the data link portion of the engagement. Only if the missiles go active immediately will this not be the case, but they generally don't do that as they need to have the target info sent to them and updated prior to going active (and how would they know when to go active?)

Add to this the fact that for the Track-Via-Missile comparisons to work, the missiles need the radar to be illuminating the target until they are cut loose.

Dont get me wrong, I am so impressed after asking for this back in the early CMNAO days and then asking for it again in this iteration, the speed at which you implemented it when the issue was explained was amazing. (For some reason I couldnt use the same username in GitHub as I do here).

[Dimitris]

So close, but not quite right. The datalink T/R elements are still on the live side of the array and are directional not omni, so they will still need to be pointing down range during the data link portion of the engagement. Only if the missiles go active immediately will this not be the case, but they generally don't do that as they need to have the target info sent to them and updated prior to going active (and how would they know when to go active?)

Add to this the fact that for the Track-Via-Missile comparisons to work, the missiles need the radar to be illuminating the target until they are cut loose.

We are aware of this. We have a separate open dev ticket (years-old one by now, in fact) about "linking [certain] datalinks to sensors". This also addresses situations like e.g. "APG-68 on F-16C must be active in order to provide mid-course uplinks to AMRAAMs, and the missiles need to be within the coverage arc". It will hopefully get its due at some point. One dragon-slaying at a time.

[bsq]

As I said at the foot of my post, I am so impressed you got this bit to work, I will hang fire on the rest. There are other ways of 'depowering' some of these systems within simple scenario design choices now that you have 'slayed' the most problematic 'dragon'. Again many thanks.

[YukariYakumo]

Very good!

[erick33]

I found a bug that could not be linked with Tacview in real time. I deleted it a few times and reinstalled it, but it was not resolved. It's like bug of a beta version

[Dimitris]

I found a bug that could not be linked with Tacview in real time. I deleted it a few times and reinstalled it, but it was not resolved. It's like bug of a beta version

It has been reported: https://www.matrixgames.com/forums/view ... 0&t=385462 . We'll get it sorted when possible.
Please report any discovered issues on the Tech Support sub-forum instead of here. Thanks!

[Mgellis]

I finally got it to download and it seems to be working well. If I spot any bugs, I'll report them.

Thanks again. This looks great so far.

[drizmans]

Whoever changed the behaviour when you left click on the map, so it deselects units and stops showing their range indicators is a true MVP! The map is feeling better with recent patches, but I seem to be getting these visual overlay issues more frequently on the betas (see screenshot). Possibly unrelated but figured I'd mention it in case it correlates with other reports.

If by chance someone who is working on the map see's this - it often feels like it should be loading in the higher resolution layers sooner than it does. I frequently find myself scrolling in more to load the higher quality textures just to zoom back out a bit, but not too much so that it loads in the lower quality textures. It would be really nice if we had an option to modify the heights at which a given resolution is loaded, since I assume this is being done intentionally to better support old PC's.

It would also be super nice if we could keep more tiles in memory. Right now the application seems to cap at a usage of just under 1GB. Modern systems typically have at least 8GB of ram, with 3-4 usable for applications. It seems to take a while to load in the higher resolution textures from the disk when you hit their trigger. This seems to be a CPU or memory bottleneck? One possible "easy solution" would raise the respective height that triggers a layer to load in a given resolution - pretty much what I suggested in the paragraph above - increasing the cache size would complement this very nicely.

The starman place names are often blurry, or contain too much information or too little. It might make sense for the placename layer to have a separately adjustable setting, so you can just load in a certain layer. Is there a reason the placenames are loaded as an image layer instead of drawn as text on the map?

Does anyone know if there is a TTL or max size to the local map cache?

[thewood1]

Right above your post...from the devs.

"Please report any discovered issues on the Tech Support sub-forum instead of here. Thanks!"

[drizmans]

Right above your post...from the devs.

"Please report any discovered issues on the Tech Support sub-forum instead of here. Thanks!"

My post was not an attempt at an issue report... As I said I'm uncertain if it always occurred, or started in the betas. I included it in case anyone else was.

[thewood1]

Thats the point of the tech forum. But its definitely not the purpose of this forum. You'll get better views of it in tech or general. Here, it'll drop off quickly.