NYGM TW 2.0 AI_Sensor.dat & SH3 Mini Tweaker

[JScones]

Originally Posted by HEMISENT

Unless I'm mistaken this just threw off the thermal layers settings for min height= in the AI_Sensors.dat file. Once I am able to get this DL'd I'll adjust accordingly

Observer's already done it. You shouldn't need to release an NYGM specific version of your mod, as NYGM already includes an updated Randomised events.cfg file which users are asked to copy into SH3Cmdr.

0_x0C35=-105 ;AI_Hydrophone
0_x0DC1=-90  ;AI_Sonar
0_x0F49=-105 ;QGAP
0_x10D1=-105 ;QClP
0_x1259=-105 ;QCeP
0_x13E5=-108 ;Type144P
0_x1571=-105 ;Type138P
0_x16FD=-100 ;Type128P 
0_x1889=-100 ;Type123P
0_x1A11=-90  ;QGAA
0_x1BF0=-88  ;QClA
0_x1DCF=-93  ;QCeA
0_x1FB2=-95  ;Type147A
0_x2195=-98  ;Type144A
0_x2378=-85  ;Type128A
0_x255B=-88  ;Type123A
 
1_x0C35=-150
1_x0DC1=-130
1_x0F49=-145
1_x10D1=-155
1_x1259=-145
1_x13E5=-150
1_x1571=-155
1_x16FD=-144
1_x1889=-145
1_x1A11=-130
1_x1BF0=-135
1_x1DCF=-125
1_x1FB2=-135
1_x2195=-130
1_x2378=-128
1_x255B=-132
 
2_x0C35=-180
2_x0DC1=-170
2_x0F49=-200
2_x10D1=-195
2_x1259=-195
2_x13E5=-215
2_x1571=-215
2_x16FD=-190
2_x1889=-190
2_x1A11=-195
2_x1BF0=-190
2_x1DCF=-180
2_x1FB2=-200
2_x2195=-190
2_x2378=-175
2_x255B=-175
 
3_x0C35=-235
3_x0DC1=-220
3_x0F49=-238
3_x10D1=-235
3_x1259=-230
3_x13E5=-235
3_x1571=-238
3_x16FD=-230
3_x1889=-235
3_x1A11=-225
3_x1BF0=-220
3_x1DCF=-215
3_x1FB2=-228
3_x2195=-225
3_x2378=-218
3_x255B=-215
 
4_x0C35=-270
4_x0DC1=-260
4_x0F49=-275
4_x10D1=-270
4_x1259=-268
4_x13E5=-275
4_x1571=-265
4_x16FD=-263
4_x1889=-265
4_x1A11=-260
4_x1BF0=-257
4_x1DCF=-255
4_x1FB2=-263
4_x2195=-260
4_x2378=-255
4_x255B=-253

[HEMISENT]

Originally Posted by JScones

Observer's already done it. You shouldn't need to release an NYGM specific version of your mod, as NYGM already includes an updated Randomised events.cfg file which users are asked to copy into SH3Cmdr.

0_x0C35=-105 ;AI_Hydrophone
0_x0DC1=-90  ;AI_Sonar
0_x0F49=-105 ;QGAP
0_x10D1=-105 ;QClP
0_x1259=-105 ;QCeP
0_x13E5=-108 ;Type144P
0_x1571=-105 ;Type138P
0_x16FD=-100 ;Type128P 
0_x1889=-100 ;Type123P
0_x1A11=-90  ;QGAA
0_x1BF0=-88  ;QClA
0_x1DCF=-93  ;QCeA
0_x1FB2=-95  ;Type147A
0_x2195=-98  ;Type144A
0_x2378=-85  ;Type128A
0_x255B=-88  ;Type123A
 
1_x0C35=-150
1_x0DC1=-130
1_x0F49=-145
1_x10D1=-155
1_x1259=-145
1_x13E5=-150
1_x1571=-155
1_x16FD=-144
1_x1889=-145
1_x1A11=-130
1_x1BF0=-135
1_x1DCF=-125
1_x1FB2=-135
1_x2195=-130
1_x2378=-128
1_x255B=-132
 
2_x0C35=-180
2_x0DC1=-170
2_x0F49=-200
2_x10D1=-195
2_x1259=-195
2_x13E5=-215
2_x1571=-215
2_x16FD=-190
2_x1889=-190
2_x1A11=-195
2_x1BF0=-190
2_x1DCF=-180
2_x1FB2=-200
2_x2195=-190
2_x2378=-175
2_x255B=-175
 
3_x0C35=-235
3_x0DC1=-220
3_x0F49=-238
3_x10D1=-235
3_x1259=-230
3_x13E5=-235
3_x1571=-238
3_x16FD=-230
3_x1889=-235
3_x1A11=-225
3_x1BF0=-220
3_x1DCF=-215
3_x1FB2=-228
3_x2195=-225
3_x2378=-218
3_x255B=-215
 
4_x0C35=-270
4_x0DC1=-260
4_x0F49=-275
4_x10D1=-270
4_x1259=-268
4_x13E5=-275
4_x1571=-265
4_x16FD=-263
4_x1889=-265
4_x1A11=-260
4_x1BF0=-257
4_x1DCF=-255
4_x1FB2=-263
4_x2195=-260
4_x2378=-255
4_x255B=-253

Oh man! Great news! Thank You Observer!
Jeasen, does the NYGM crew/Observer have a copy of the sabotage/malfunctions files (the Sensors.dat files u boat radars max range= has been edited or is this irrelevant at the time)I sure wish I could Dl this but i'm still limited to 169mb.

Off Topic-"DON"T GET DIRECWAY SATELLITE SERVICE!"

[JScones]

Whilst Observer has created new files with the mal/sab inclusions, they
are not in the current NYGM release (understandably, as the current SH3Cmdr would not work with them anyway).

Observer will need to update the NYGM d/l file when R2.6 is released, or provide the files via separate d/l.

[lurker_hlb3]

HEMISENT

Not to worry. The only binary files that were changed was AI_Sensor.dat and the *.zon files for the subs.

[Rose]

I know I'm kinda being a pest but... could someone explain this in REALLY simple English for me please and none of this cyber talk? If I already copied those NYGM files into SH3Cmdr when I DLed NYGM, there is no need to copy the changes Lurker has made?

[JScones]

Correct. You don't need to follow any of this thread unless you use SH3 Mini Tweaker to personalise the settings in AI_Sensors.dat.

If you simply want to play NYGM, wipe this thread from your mind and just follow the NYGM installation instructions.

[Totenkopf]

Awesome! Some modders info that helps the community, well done lads!

[Rose]

Originally Posted by JScones

Correct. You don't need to follow any of this thread unless you use SH3 Mini Tweaker to personalise the settings in AI_Sensors.dat.

If you simply want to play NYGM, wipe this thread from your mind and just follow the NYGM installation instructions.

All right, thanks .

[Observer]

Originally Posted by HEMISENT

Oh man! Great news! Thank You Observer!
Jeasen, does the NYGM crew/Observer have a copy of the sabotage/malfunctions files (the Sensors.dat files u boat radars max range= has been edited or is this irrelevant at the time)I sure wish I could Dl this but i'm still limited to 169mb.

Off Topic-"DON"T GET DIRECWAY SATELLITE SERVICE!"

I've two pieces of feedback on the malfunction and sabotage settings used in the Randomized events.cfg. The first is on the crash dive settings simulating a jammed dive. While I understand the intent, consider the implications for those situations where the crash dive depth is deeper than the crush depth of the submarine. This will result in odd uboat behavior described in the Crash Dive Blues thread here:

http://www.subsim.com/radioroom/show...ash+dive+blues

This is because your uboat will not be able to complete the crash dive sequence - a necessity otherwise it's outside of the ability of the code to really handle this aspect. It's not that bad on the stock uboat models because of the extra positive buoyancy, but with the NYGM model it's a disaster that can't be corrected unless you surface.

The other area is the Front/Rear ratio. Similar to the crash dive problem above, this is an area that probably shouldn't be touched. Again, the extra positive buoyancy of the stock models makes this less of a challenge, but it is still present an uncorrectable, a situation that really not possible since internal trim tanks and dive planes can usually compensate. If not then additional speed will usually solve the problem. This is another area SH3 does not model well.

Finally, is there any consideration to storing the malfunctions or sabotage settings so that:

1) By the freak of random chance you don't keep getting hit by the same problem multiple times when reloading
2) Problems can be compared to a "repair table" so that a certain number of days (or hours) in game must pass before the problem is removed (at the next reload). Malfunctions could also be flagged as not repairable at sea (i.e. persistent). I am troubled by the possibility that I could, in theory have an equipment malfunction, end my session for the night (save and exit) then reload the next day to have the problem magically disappear.
3) Or are all problems persistent? If so then the point I outlined above on the F/R ratio really needs consideration, and I think you should consider that not all "malfunctions" are persistent.

It's a great idea. These are just my thoughts FWIW.

[HEMISENT]

Originally Posted by Observer

I've two pieces of feedback on the malfunction and sabotage settings used in the Randomized events.cfg. The first is on the crash dive settings simulating a jammed dive. While I understand the intent, consider the implications for those situations where the crash dive depth is deeper than the crush depth of the submarine. This will result in odd uboat behavior described in the Crash Dive Blues thread here:

Your right, however when putting together the Sab/Mal mod I had no idea what was in the works with NYGM V2. As I understand it if you do not allow the crash dive to complete it's cycle the boat handles goofy with your anti-hummingbird settings. Obviously a few things will need to be changed around which is what I expected.

Originally Posted by Observer

The other area is the Front/Rear ratio. Similar to the crash dive problem above, this is an area that probably shouldn't be touched. Again, the extra positive buoyancy of the stock models makes this less of a challenge, but it is still present an uncorrectable, a situation that really not possible since internal trim tanks and dive planes can usually compensate.

Another case of both of these projects going together at the same time.
As for the effects of f/r ratio in the std game they're just another semi-subtle annoyance to be dealt with but if it is as you say then the anti-hummingbird settings should give the player enough of an additional workout. I have no problem deleting the "trim" malfunction.

Originally Posted by Observer

Finally, is there any consideration to storing the malfunctions or sabotage settings so that:

1) By the freak of random chance you don't keep getting hit by the same problem multiple times when reloading
2) Problems can be compared to a "repair table" so that a certain number of days (or hours) in game must pass before the problem is removed (at the next reload). Malfunctions could also be flagged as not repairable at sea (i.e. persistent). I am troubled by the possibility that I could, in theory have an equipment malfunction, end my session for the night (save and exit) then reload the next day to have the problem magically disappear.
3) Or are all problems persistent? If so then the point I outlined above on the F/R ratio really needs consideration, and I think you should consider that not all "malfunctions" are persistent.

It's a great idea. These are just my thoughts FWIW.

1)As far as being hit by the same problem multiple times-I suppose it's possible but has never happened to me yet.

2 & 3)Jscones and I went back and forth a bit about repairable vs non-repairable during a mission. It all boils down to "you can't please all the people all the time". It was decided to split the difference. As of right now the miscellaneous malfunctions are "non-repairable"(guns/radar/snort/scope etc.. The individual boat malfunctions engine/steering/battery etc are "repairable". Each player can easily go into Randomized events.CFG and change his settings to whatever may suit his individual preferances.

As I recall one option was to make a second seperate set of files, one set would be repairable and one set would be good for the entire mission.
Sort of like randomizing the random files. You may get an engine problem that will be "repaired" by save/exit or you may get the same problem that persists for the entire mission. What do you think?

In the end I did not want every single malfunction or act of sabotage to be debilitating for the entire mission. Some are definately going to require an immediate RTB while others will simply have to be dealt with by an ingenious crew. Others are borderline and it will be up to the Captain's discretion.
Please let me know your thoughts on this.

[Observer]

Originally Posted by HEMISENT

Your right, however when putting together the Sab/Mal mod I had no idea what was in the works with NYGM V2. As I understand it if you do not allow the crash dive to complete it's cycle the boat handles goofy with your anti-hummingbird settings. Obviously a few things will need to be changed around which is what I expected.

Another case of both of these projects going together at the same time.
As for the effects of f/r ratio in the std game they're just another semi-subtle annoyance to be dealt with but if it is as you say then the anti-hummingbird settings should give the player enough of an additional workout. I have no problem deleting the "trim" malfunction.

No problem and I understand. I've sent a set of files to Jaesen with my suggestions and the necessary modifications to the hex offsets to support R2.6. I can PM you the link if you want. The only thing I can think of is the crash dive depth, and I haven't looked into this yet. You might consider setting the crash dive depths to something like 150 or 175 meters. It should have the desired effect.

1)As far as being hit by the same problem multiple times-I suppose it's possible but has never happened to me yet.

Okay.

2 & 3)Jscones and I went back and forth a bit about repairable vs non-repairable during a mission. It all boils down to "you can't please all the people all the time". It was decided to split the difference. As of right now the miscellaneous malfunctions are "non-repairable"(guns/radar/snort/scope etc.. The individual boat malfunctions engine/steering/battery etc are "repairable". Each player can easily go into Randomized events.CFG and change his settings to whatever may suit his individual preferances.

As I recall one option was to make a second seperate set of files, one set would be repairable and one set would be good for the entire mission.
Sort of like randomizing the random files. You may get an engine problem that will be "repaired" by save/exit or you may get the same problem that persists for the entire mission. What do you think?

In the end I did not want every single malfunction or act of sabotage to be debilitating for the entire mission. Some are definately going to require an immediate RTB while others will simply have to be dealt with by an ingenious crew. Others are borderline and it will be up to the Captain's discretion.
Please let me know your thoughts on this.

Given the choices I like the option of two different files the best. The only thing I'm a little bugged about is the save and exit "repair", but I suppose those who choose to use this system probably wouldn't consider cheating it with a save and exit.

The advantage of the two files is customization. People can choose which malfunctions, if any are repairable or not. That should help satisfy a wide variety of people.

You've got a good set of reasonable malfunctions. Based on my experience, the diesel malfunctions should be be very difficult to repair at sea. Major combat or propulsion systems malfunctions should cause an abort. I would consider the diesels, electric engines/battery and torpedo tube system malfunctions should be abort status. Lesser combat systems failures such as the periscope (unless both fail), hydrophone, radar, guns, etc. probably would not, but should be at the CO's discretion.

While I'm thinking of it, you don't model any torpedo tube failures. That would be a great one to add. A couple of other things while I'm thinking on it. I don't think the RPM effects do much of anything at all. Same with electric engine HP. I've modified both it and never found it to do anything. Not even hydrophone detection. That's controlled by the speed multiplier in the submarine cfg files.

Oh, one other question. Do you get a warning message, or some sort of notification when starting SH3 Commander that you've had a malfunction? I think that (like the transferred crew message) would be a nice addition if it's not already present.

[HEMISENT]

Originally Posted by Observer

While I'm thinking of it, you don't model any torpedo tube failures. That would be a great one to add. A couple of other things while I'm thinking on it. I don't think the RPM effects do much of anything at all. Same with electric engine HP. I've modified both it and never found it to do anything. Not even hydrophone detection. That's controlled by the speed multiplier in the submarine cfg files.

I know the RPM's are not modelled, I only did them so they would be visibly dropping when viewed from control room(eye candy) I've noticed that sometimes the tachometer registers the change and sometimes it doesn't(game bug?)
Also. I too thought torpedo tube failure would be great but have no idea where to look to either "cancel" a tube out or even effect load times.
Any clue in that direction would be appreciated.

Originally Posted by Observer

Oh one other question. Do you get a warning message, or some sort of notification when starting SH3 Commander that you've had a malfunction? I think that (like the transferred crew message) would be a nice addition if it's not already present.

No, I was dead set against any kind of warning or message as these were supposed to be a surprise. Also, the captain absolutely, positively must make a test crash dive (as in real life) plus a basic test of his major systems at the beginning of every patrol. It would be very unsettling to run into a juicy convoy with no escorts go to PD, raise your perscope and only to find out that the seals are bad and it stays blurred then go to the Obs scope and find a problem there too.(there is only one file that affects both scopes and the Obs scope does clear up after a bit)

[Observer]

Originally Posted by HEMISENT

I know the RPM's are not modelled, I only did them so they would be visibly dropping when viewed from control room(eye candy) I've noticed that sometimes the tachometer registers the change and sometimes it doesn't(game bug?)
Also. I too thought torpedo tube failure would be great but have no idea where to look to either "cancel" a tube out or even effect load times.
Any clue in that direction would be appreciated.

Load times are in the NSS_Uboat*.sim files. For the TypeVIIb, the hex offset for the loading time in the bow torpedo room is x0972. The aft torpedo room is x09E8. Fwd external is x0A6C, and aft external is x0AE2.

I'll have to work on the torpedo tubes. I have a couple of ideas I'll have to test to be sure.

No, I was dead set against any kind of warning or message as these were supposed to be a surprise. Also, the captain absolutely, positively must make a test crash dive (as in real life) plus a basic test of his major systems at the beginning of every patrol. It would be very unsettling to run into a juicy convoy with no escorts go to PD, raise your perscope and only to find out that the seals are bad and it stays blurred then go to the Obs scope and find a problem there too.(there is only one file that affects both scopes and the Obs scope does clear up after a bit)

I understand what you are saying, and it might be true at the beginning of a patrol on some systems (the controlled dive after leaving port to test systems is a good example where this would be true), but not in the middle of a patrol and not for important system failures. The captain has other crew members to help him keep track of the material status of his boat. He shouldn't find out the optics of the attack periscope have failed for the first time when he getting ready to shoot during a convoy attack (assuming there was a save and exit during the approach and attack phases). I would keel haul my engineer if I found out the attack scope was broke when I went to raise it and he didn't bother to tell me first. It's why submarines have out of commission (OOC) and reduced status logs. It's why submarines have an engineering, weapons and navigation departments. It's their job to keep track of the material status of their equipment and fix it when it's broken or in a reduced status. It's their job to tell the captain when their equipment doesn't work.