Matrix Games Forums

ORIGINAL: SuluSea

I don't want to rain on anyones parade and appreaciate greatly Michealm and his tremendous support but I see daily requests being made for new features. I fear at some point if new features keep being added the game may be unplayable to the new player . Again thanks Micheal for the outstanding support.[:)][:)]

The majority of changes tend to be tweaks to existing things or additional information added.
I don't see these changes as being too radical to totally confuse a new player (unless he has actually read the manual[:D]. In which case there will be extra stuff on screens that might not be obvious.) It is not as if certain aspects were totally turned "topsy-turvy" as I have seen in other 'patched' games.

SuluSea, quite a vast number of changes have made the interface easier and greatly reduced click-count, both of which should make life much easier for a new guy - compared to previously, of course, not that this will ever be a trivial game to learn.

ORIGINAL: witpqs

ORIGINAL: witpqs

ORIGINAL: michaelm



No. The limits are visible on the lcu list screen and the base screen.

Just had a thought that it probably wont be visible if the LCU is in a non-base screen. Unless the LCU list is shown.

Doing hotkey scans of the map seems to stretching the performance of this code at this time.

Understood. As an alternative, could the stacking limit for the currently selected hex be displayed somewhere on the screen? That would only be 1 hex at a time but would meet the need of a player who had to check on a hex (which I anticipate to be needed reasonably often until/unless people become very familiar with the limits in any given area of combat).

Michael, just in case you are entertaining this suggestion, here are a couple of possible locations:

I have gone with your option 1, adding a few spaces after the hex location before printing it. That way it will 'float' with the size of the 'Hex: x,y' string.
Will be in the next build.
Thanks

Michael, greate thanks for your support!

I have some questions regarding Fixed Defender pilot not always getting fatigue from high altitude penalty [MEM].

I think it is a very good idea as it brings the air combat down from the max altitude but still allows it at least for a few attacks.

1.) Just a short question, would it be possible to further increase the morale malus for hight altitude fighting ? I think it is quite a good idea to balance it that way but the hit on the morale is still not very hight and you can conduct strato sweeps for quite a lot of turns. It is currently only a real problem with cap at max altidude.

2.) Would it be possible to "color" the altitude settings to yellow if the altitude of a plane is in the morale malus range ? It is quite hard to set a good cap for multiple planes that does not have the morale malus. And it is a lot of micromanage to calculate it for each plane and then set the corresponding cap. And i usually do not change the cap altitude each turn, i set it once and then it is set.

3.) A more, lets say, advanced question is the following. Until now when i decided to set the alt of a base with 10 different fighter plane squads i picked the one with the most alt and most range, turned the droptanks on and then i used the set all fighters button. This automatically set all planes to max range and max altitude. Now this is a little problem as i would push some of the groups in the morale malus range. Would it be possible to just change the "percentage" of all other groups ? So i set my P47D25 to 30k alt, which is around 70%. Now when i press the set all fighters, all fighters are set to 70% of their max altitude and no longer to 30k for each. Same rule goes to all planes which have a morale modifier with alt. Problem is that the flat height should remain (at least i think) as for example if i have a HR for 15k feet for 4E i want to set all 4E to 15k feet and noone lower.

Just some suggestions to improve the usability, no big game changer. But the morale malus added some micro management again.

ORIGINAL: michaelm

ORIGINAL: Bliztk

Hi michael, we are experiencing overkill ratios with night bombers:

tm.asp?m=2941270

Can you check if anything got changed recently ?

We are recently upraded from mid August to 26th Oct Beta

No changes to Night air combat apparent in current betas.

[edit]
attach a save with bad combat and I'll see if any of the other changes might have had a knock on effect.

Attached savegame

Using 1108q9b, Operation Buccaneer, under the Intelligence/Ship Availability screen the sort function doesn't appear to be working on either the Type column or the ETA column.

It's only a small thing, but I understand there is some sort of deity in the details.[:)]

Works okay in my saves.
Post a save. There might be some corruption in a ship name or such.

Here ya go.

ORIGINAL: michaelm

I have gone with your option 1, adding a few spaces after the hex location before printing it. That way it will 'float' with the size of the 'Hex: x,y' string.
Will be in the next build.
Thanks

Thanks! [:)]

ORIGINAL: witpqs

ORIGINAL: michaelm

I have gone with your option 1, adding a few spaces after the hex location before printing it. That way it will 'float' with the size of the 'Hex: x,y' string.
Will be in the next build.
Thanks

Thanks! [:)]

+1

[&o][&o][&o]

ORIGINAL: dorjun driver

Using 1108q9b, Operation Buccaneer, under the Intelligence/Ship Availability screen the sort function doesn't appear to be working on either the Type column or the ETA column.

It's only a small thing, but I understand there is some sort of deity in the details.[:)]

Taskforce arrival is throwing it for the ETA. The sort is looking at the SHIP's arrival date, not the TF. The ship is probably at 0 delay. I can fixed that.

The Type sort though looks okay to me. It is by the class type 'number' not the text letters.

ORIGINAL: Bliztk

ORIGINAL: michaelm

ORIGINAL: Bliztk

Hi michael, we are experiencing overkill ratios with night bombers:

tm.asp?m=2941270

Can you check if anything got changed recently ?

We are recently upraded from mid August to 26th Oct Beta

No changes to Night air combat apparent in current betas.

[edit]
attach a save with bad combat and I'll see if any of the other changes might have had a knock on effect.

Attached savegame

I've run this save and the night attacks seem almost non-existent compared to the stated results you mentioned elsewhere.
Is this the save from that replay???

ORIGINAL: michaelm

ORIGINAL: Bliztk

ORIGINAL: michaelm


No changes to Night air combat apparent in current betas.

[edit]
attach a save with bad combat and I'll see if any of the other changes might have had a knock on effect.

Attached savegame

I've run this save and the night attacks seem almost non-existent compared to the stated results you mentioned elsewhere.
Is this the save from that replay???

Ohhh, this is what I was afraid of ... so many variables involved that getting repeatable results to show an issue is almost impossible ...

Maybe I missed the combat replay file. I have rerun the turn in my computer and I get this anomalous results

ORIGINAL: michaelm

ORIGINAL: dorjun driver

Using 1108q9b, Operation Buccaneer, under the Intelligence/Ship Availability screen the sort function doesn't appear to be working on either the Type column or the ETA column.

It's only a small thing, but I understand there is some sort of deity in the details.[:)]

Taskforce arrival is throwing it for the ETA. The sort is looking at the SHIP's arrival date, not the TF. The ship is probably at 0 delay. I can fixed that.

The Type sort though looks okay to me. It is by the class type 'number' not the text letters.

Roger. And thanks again.

By the way, whatever you're on? Where might I procure a taste?[:'(]

ORIGINAL: PaxMondo

ORIGINAL: michaelm

ORIGINAL: Bliztk



Attached savegame

I've run this save and the night attacks seem almost non-existent compared to the stated results you mentioned elsewhere.
Is this the save from that replay???

Ohhh, this is what I was afraid of ... so many variables involved that getting repeatable results to show an issue is almost impossible ...

One thing we've seen on these boards over the years is complaints about certain results which make it seem like all examples of that function are like those results. Often it turns out to not be the case.

If night bombing results are really all over the place and only sometimes result in significant success then that doesn't seem too bad to me. What do you think?

One thing I have found is that airborne search radar is not being checked before the planes are spotted, but is used in the actual plane-to-plane combat.
Logically, if planes have no radar and no detection from the ground, then actual interception should be less likely.
The reason I noticed this is that there is a slot to record the air radar device of the defenders, but in the few night combats in this save, there was no value stored there.

I have added a simple check for radar in the CAP or raid being detected in this build. It should lower the odds that CAP without some radar assistance will engage raid. NF or a/c with air radar should do better at intercepting raids than those without.

Feedback appreciated.

ORIGINAL: michaelm

One thing I have found is that airborne search radar is not being checked before the planes are spotted, but is used in the actual plane-to-plane combat.
Logically, if planes have no radar and no detection from the ground, then actual interception should be less likely.
The reason I noticed this is that there is a slot to record the air radar device of the defenders, but in the few night combats in this save, there was no value stored there.

I have added a simple check for radar in the CAP or raid being detected in this build. It should lower the odds that CAP without some radar assistance will engage raid. NF or a/c with air radar should do better at intercepting raids than those without.

Feedback appreciated.

Oh, I cannot wait to test this! THANK YOU!!!!!

[&o][&o][&o]

Michael,
I have a question WAD or not noticed before regarding pilot movement. Beta 1108q9b

The Japanese Datai that have detached units. When trying to add replacement pilots (35 quality pool) to detached unit then it will draw from the top of the parent unit not the replacement pool. Then you can go to parent unit and fill with replacements no problem.

However, the units that are split with fighter group parents and recon detached units will consistently bring in the skilled fighter pilots into the recon unit rather than replacements for recon training purposes.

Fix possible??