NYGM TW 2.0 AI_Sensor.dat & SH3 Mini Tweaker

[Totenkopf]

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

[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.

[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 .

[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.

[HEMISENT]

Observer, I thought those lines looked familiar so I went back to my notes and sure enough I did check them out. Turns out that I did run some tests with those exact same files in mini tweaker- no changes noted at all no matter how ridiculous I set them. Possibility exists that they're dependant upon some other value that I'm not aware of. Most of my tests used Type VII's as base. Tests were performed using crew @ full energy levels w/compartment fully staffed. NYGM TW 1.03 used as base mod. If you can come up with something that would be great. A torpedo loading malfunction would be a nice addition-better yet would be the disabling of a complete tube or two for Sabotage files.