Gap, do you have accurate data of the number of shells/bullets on board subs for the deck and AA guns?.. want to make a complete revision of the weapon files for my mod-pack..
:salute:

Yes, more or less...

According to "Warship Pictorial 27 - Kriegsmarine Type VII U-Boats", some typical U-boat's AA armaments would have been as follows:

- types VIIA, VIIB and VIIC: 1 x 20 mm C/30 gun with 1,100 rounds;
- type VIIC/41: 1 x 37 mm SK C/30U gun with 1,200 rounds and 2 x C/38 twin mount guns with 4,400 rounds

I don't know how corrected is this information. For sure it is not complete. Anyway, I would assign 1,100 rounds to each 20 mm gun (2,200 for twin mountings and 4,400 for quad) and 1,200 rounds to each 37 mm gun (2,400 for twin mountings), though I admit that these loadouts could result a bit excessive if the player equipped his boat with multiple twin and quad flak guns.

Unfortunately, afaik there's no way to limit the maximum number of rounds of a given type which can be carried aboard the sub (in game the total loadout is determined by the sum of the rounds assigned to each gun), whereas the small space aboard a real U-boat would have posed serious limitations.

Regarding outfits, Navweps reports about 25% of AP incendiary and 75% of HE incendiary rounds, for the 20 mm flaks. Nonetheless, according to "Naval Weapons of World War Two" by John Campbell, early outfits might have included HE rounds alone. As for 37 mm guns, according to the above sources, outfits were only HE with tracer for the SK C/30U gun, and 2/3 HE incendiary, 1/3 AP with tracer for Flak M42.

In respect to the 88 mm deckgun, the loadout reported by Warship Pictorial is 160 shells for the type VIIA, and 220 for the remaining models. According to Campbell, outfits for U-boats included exclusively HE and HE incendiary, with AP and starshells carried onboard minesweepers and subchasers alone. :yep:

Good news, I think! Now it seems that all the different malfunction values work in different dates, even TDW's duds. If this is true, we don't need to clone the torpedoes.

I couldn't find any difference in custom missions concerning the different time periods. But when I tried my malfunction mod in campaign, there was a clear difference. Could it be that I don't know how to set the right date in the mission editor? I get the right date in the custom mission menu, but when in mission I click the log, it always reads first of june 1940 or something like that. And I always get the same radio message about mines being planted on British coasts. It's like the game is using year 1940 to simulate radio messages, maybe also torpedo loadouts? Similiar experiences?

Anyway,it looks good right now! I think I'm going to need some testers soon!

Hi Rongel.

When you open your misge-file with notepad, first section, is the current date value same as date value?

Hi! No, the years are different, current year was the mysterious 1.1.1940, maybe this is the reason why I didn't see any difference in the results! Need to test this later, thanks! :salute:

Thank you, sir :)

It was very informative :up:
:salute:

:Kaleun_Party: :Kaleun_Thumbs_Up:

Yes, from what you are saying, it seems you alway tested the same date :doh: :D

There are 3 start date parameters which can be set in ME2. The first one is set from the 'add new mission' menu. The second start date box is found on the top bar and gets available for editing after adding a new mission, and the last one is accessed from menu Mission => Parameters.

I Ignore what is the exact meaning of these apparently similar parameters, but in order to avoid surprises I usually set the three of them to the same date ;)

My pleasure, mate :salute:

:Kaleun_Thumbs_Up::Kaleun_Applaud::Kaleun_Party:

Glad to hear you are still working on it Volodya:sunny:

I tried this again, changed all three parameters with my own date, but when I open the .misge file there is again this mysterious year:

CurrentYear=1940
CurrentMonth=1
CurrentDay=1
CurrentHour=0
CurrentMinute=0

So I changed that also to my liking, and a vot! Everything works like it should, there is a correct date on the mission log, and all the torpedo malfunctions work like they should, no question about it! Only thing that I don't know if it works or not is the low speed malfunction reduction... well soon find out, after that it's just putting the data in right places. :sunny:

weird... :hmmm:

...but who cares: :D
now it is time to celebrate your outstanding news :woot: :yeah:

I think I have finally understood how the two start_index and end_index parameters (trav/elev gun_anim groups) are working for sub guns. Their format is in seconds, and they determine the actual min/max training and elevation angles.

Imagine that gun's animation, as previewed in Goblin Editor, was as a movie. We see it in a loop, but in reality it got a start and an end. If we wanted to set gun's min elevation, we should set as start_index the offset in second from the start of the movie corresponding to the desired minimum elevation angle. Likewise for maximum elevation. We should then set the min and max elevation parameters according to the agles that start and end idexes are pointing to in the animation.

For what I've seen min/max settings, determine the aiming of the gun when manned by the crew, whereas the trajectory of the fired shells is aligned with muzzle's z axis. If min/max settings are not matched with start/min index settings to represent the same (or very similar) angles, the gun gets crazy, because AI sees a different elevation than actually is.

If for example, end_index points to an elevation in the animation which is lower than the one set as max gun's elevation, our gunner will aim regularly below the target. Likewise, if max elevation is lower than what would be expected after compairing end_index with gun's animation, AI will aim on top of the target, no matter what is crew's experience. :yep:

This explains why, if we reduce max elevation without adjusting end_index, we obtain an opposite result than expected: far from having a reduced max elevation, the gun will be always over-elevated by the crew, whereas its elevation range will remain unchanged ;)

Well.. can you explain it again, but now, like for child in kindergarten? maybe with numbers will be clearer.. :oops: :D

Okay :up:

Imagine gun's animation as a movie. Let's say that its duration is 5 seconds and that the first and last photograms are equal respectively to -20 and +80 deg.

If we wanted our gun to have an in-game elevation range of -10/+30, we should set accordingly elevation start_index and end_index. Since animation's angular range is equal to 80 - (-20) = 100 deg, we would calculate index settings as follows:

start_index = [-10 - (-20)] deg * 5 sec / 100 deg = 0.5 sec
end_index = [30 - (-20)] deg * 5 sec / 100 deg = 2.5 sec

These settings will determine the visual min/max elevation of the gun, and therefore the trajectory followed by its rounds. Now we have to set min and max elevation accordingly:

min = -10
max = 30

This is the elevation range seen by the AI, when aiming the gun. If we missed to match the visual/balistic range (start_index and end_index), and the aiming range (min and max), the mismatch would lead to wrong aiming, so simple :yep:

The only problem is that with the currently available tools, we cannot read from file neither animation's duration nor min/max elevation angles set in the animation. We can only estimate them or desume them from stock settings, provided that the latter are not wrong (btw: they are in many cases ;) :-?).

Thanks.. more clearly.. :up:

PS: I feel like a boy with Down syndrome.. perhaps it's time to go to sleep.. :D