Malfunctions/Sabotage in SH3Cmdr???

[JScones]

As you would have read here (http://www.subsim.com/phpBB/viewtopic.php?t=49873&postdays=0&postorder=asc&start=0), Hemisent has done some great work on developing randomised u-boat equipment malfunctions and simulated damage caused by sabotage. These creations utilise SH3Cmdr's recently added "randomised events" feature.

I'm keen to gain your feedback, as SH3Cmdr users, on whether any or all of his creation should be included as "stock" in SH3Cmdr R2.6. As the changes share the generic "Randomised events.cfg" file, it is not feasible to add a specific selectable option to SH3Cmdr. Hence any additions will automatically execute unless manually removed.

If after reading teh above thread you need further clarification of content, I'll have to defer to Hemisent. I'm sure he'll be happy to answer any specific questions.

[kiwi_2005]

Malfunctions with sabotage overlayed. :rock:

[Salvadoreno]

everything!! combined!!!

[Gizzmoe]

"Malfunctions with sabotage overlayed" sounds good, but only as an option, not as default.

[GreyOctober]

The tougher it gets, the better! Overlayed! :up:

[Scorpius]

I dont like sabotage but certainly defects.

[Mr.Fleck]

I vote for both combined. If possible effects (especially sabotage) should only change from patrol to patrol and not every time the user starts SH3 Commander.

Cheers
Mr. Fleck

[JScones]

I vote for both combined. If possible effects (especially sabotage) should only change from patrol to patrol and not every time the user starts SH3 Commander.
Good point about sabotage events not randomising mid-patrol. Hemisent, something to consider, if haven't already?

[U-Schultz]

I voted for malfunctions only.

I think the "sabotage" angle, that seems to be very prominent in some U-boat histories, is way overdone. I have no stats to back up this feeling but if you read mid to late war histories I rarely read of a breakdown or malfunction...the word "sabotage" is always used.

Its difficult for me to imagine that the U-Boat arm could be so sloppy as to allow (seemingly) constant tampering of their boats by foreign dock-workers.
I would guess that poor quality parts, overworked or tired techs, lack of proper parts, increasingly inexperienced crews, and the rush to get returning boats back to sea, are the main cause of problems not "sabotage."

Again, that is my opinion based on years of reading and study.

On a more practical note did I read correctly, in the other thread, that any malfunctions generated will not be repairable at sea (in-game)? i.e., through the standard SH3 repair process?

EDIT: Could this feature be made a "check-box" selectable option in SH3 Commander? Perhaps selectable like the Fatigue models..."Malfunctions Only" or "Malfunctions and Sabotage."

Thx

[irish1958]

The BEST of all would be a check box to use or not use one or both mods. I for one would like them both. As for not repairing in mid patrol, any good sabotager would pick something that couldn't be fixed easily or at all.
This is a game and should be fun. It should invoke a response from the player, and nothing gets a response better than when something you can't do anything about goes wrong.
I had a great career going once and CMDR retired me. I was really pissed off, but that's life; and that is realism.
DTB states that the lack of uncertainty is a draw back to realism. I fully agree and enjoy it in a game where things I can't control screw up my plans.
This is the only game I have ever played more than a few times and the reason is the uncertainty, and the wonderful variability supplied by its great modelers. Increasing them will only make it better.
I don't have the computer skills to implement these changes myself, so I rely upon you (all) to make them available for me.
irish1958

[mike_espo]

Fantastic Idea! :up: All accounts of U-boat operations mention the "odd" malfunction of systems.

:rock:

[Heibges]

If neither is repairable, neither should occur on more than 1% or 2% of patrols. What I would really like is breakdowns that are repairable on all patrols, and sabotage, again, on maybe 1 or 2% or patrols.

I would say not make them a part of SH3 Commander, but have them as seperate JGSME.

[SkvyWvr]

:ahoy: I'd like the flexability of adding the features myself

[VonHelsching]

My vote goes to malfunctions.

[U-Dog]

malfuntions, some repairable at sea others not.

[HEMISENT]

Right now as it stands Ive completed all the Sabotage files. 3 basic periods are included 19440601, 19440801and 19450101 each has a gradually increasing percentage. Files have been sent to Jscones as individual sets plus a merged set using his date specific function. He can utilize them however he sees fit.
As for the Malfunctions component I already have a year by year set of files completed and I'm now finishing merging them for the date specific function.
What I'm looking for is one file called Randomized events.CFG that begins at the start of the war and runs thru the end with similiar files using different percentages kicking in/loading at specific dates.

The percentages differ year to year and boat type to boat type eg: the VIIB & IXB were older models and are set up with slightly worse odds than the newer C models

I've played with the percentages and right now for the initial version:
1939= 10-20% initial stages of war
1940-mid 1944=15-20%
Most of the files are set to be able to be repaired mid patrol-that means that should you be on a mission and notice a malfunction the player will have the option of continuing the mission as is and compensating for it or simply exit/re-launch thru Commander. I did this in the interest of those players who do not play at the upper edges of difficulty. The fact is if you take a boat out, test the engines and find out that it's only capable of max speed 9kts it's your decision to continue on or RTB. In any event the decision to continue is totally in the hands of the player.
Regarding percentages, we all agree that everyone has a different style of gameplay and expects different results from the same game. Once these malfunction files are out and being used; should a player decide that he's unhappy with the percentages(too much/too little) the player can easily go into SH3 Commander/CFG/Randomized events.CFG and locate the type boat he's concerned about and change the percentage to his own liking. Commander is infinitely adjustable in this regard.

As of right now all that's left is to finish merging the IXD2 and XXI boats.
Jscones needs to look at my merged file structure to make sure I didn't screw the formatting up since the date function is still new and in testing
Then it's up to him.

For addl info or thoughts see the Sabotage thread.

Cheers!

[Deep Six]

Just a thought, is there anyway of locking down the sabotage whilst still in dock thus inceasing you stay in port or even maybe the unlucky chance of your boat sustaining enough damage to actually have you to change your boat , throwing in a randomiser as to what you might end up with (You loose your beloved VIIc) for a VIIb?

Malfunctions should be a random occurance whilst on patrol as to what effect or % I'll leave that to you great modders

Just a thought

Deep Six

[Scorpius]

Well i spose if sabotage does end up making it in the final, i guess i could easily start patrol and check my boat before leaving port and re-dock if sabotage was found. Its not totally unrealistic but it would just annoy me too much to have sabotage.

I am all for malfunctions that are undetectable and non-crippling of a uboat. Like for example tube cap on tube 3 is malfunctioning whereby it cannot be opened or port electric engine has a faulty bearing or seal which causes the engine to not run efficiently effectively reducing maximum speed underwater by 1/4.

That is the kind of thing i would like - well not really like as its a malfunction! But you get the idea. Its like the dud fish. I hate it when it happens but i would rather have that in the game than not.

[Enfilade]

I'm for combined malfunctions/sabotage. I do have one question: if 2.6 is to be the final Commander and the sabotage/malfunction element is built in... what happens when the malfunction/sabotage mod is updated to a newer version? I would hate to lose the entire functionality of Commander if the newer version caused some conflict.

[JScones]

I am all for malfunctions that are undetectable and non-crippling of a uboat. Like for example tube cap on tube 3 is malfunctioning whereby it cannot be opened or port electric engine has a faulty bearing or seal which causes the engine to not run efficiently effectively reducing maximum speed underwater by 1/4.

That is the kind of thing i would like - well not really like as its a malfunction! But you get the idea. Its like the dud fish. I hate it when it happens but i would rather have that in the game than not.
That's what I think the beauty is. Nothing is destroyed, just made less effective. For example max speed may be slightly decreased to reflect engine damage. Periscope raise time may be slower to reflect bearing/whatever wear and so on.

What this does is:
a) make the need to do a test crash dive just out of port a necessity rather than a useless process step (for those that take their game seriously)
b) adds an extra element of thinking..."Gee, it takes two seconds longer to dive and I'm in 1944...should I continue my patrol, or should I go home?". You then become responsible for your decision - which really hits home if five minutes later you're hit/sunk by a roming Catalina whilst trying to dive. Extra choices and decisions...more uncertainty...BRILLIANT!

[HEMISENT]

what happens when the malfunction/sabotage mod is updated to a newer version? I would hate to lose the entire functionality of Commander if the newer version caused some conflict.

The Sabotage/Malfunction mod is nothing more than a long text file which can be copy/pasted right into the Randomized events.CFG in Commander.
Any updates or revisions can be swapped very easily. The mod is being put together specifically for Commander 2.6. Thermal Layers is already working properly in Commander and Sabotage/Malfunctions is written the same way only utilizing the new date function.

[Scorpius]

Meh! We shall see how this pans out.

[JScones]

I'm for combined malfunctions/sabotage. I do have one question: if 2.6 is to be the final Commander and the sabotage/malfunction element is built in... what happens when the malfunction/sabotage mod is updated to a newer version? I would hate to lose the entire functionality of Commander if the newer version caused some conflict.
That's why I've spent so much time on the randomised events and static settings features. In my mind they have now become the heart of SH3Cmdr.

It's these two features in particular that ensures that SH3Cmdr never gets "outdated" for SH3. If in one month someone comes up with a great new malfunction idea, it just gets added to the randomised events framework. When gouldjg has finished his CHAOS mod, it can be plugged in too.

And that's the main reason why I don't have any future release plans. I've now made basically all SH3Cmdr settings adjustable via cfg files, so it can continue to be "tweaked" just like SH3 can.

[HEMISENT]

I vote for both combined. If possible effects (especially sabotage) should only change from patrol to patrol and not every time the user starts SH3 Commander.
Good point about sabotage events not randomising mid-patrol. Hemisent, something to consider, if haven't already?

Jaesen
That's what I originally intended but the issue came up regarding being "stuck" with the problem with no ability to repair. Personally I like the idea but in the interests of those who would have a problem with it I changed it to "repairable"(exit/re-launch) mid patrol. It's a simple thing to change-so let's have some feedback on this if possible.
Here's a thought-I suppose I could just duplicate each file and re name them 0_data (mid patrol), 1_data(no mid patrol), etc. Then increase the Number in the choose from= line to control the odds.
This way the player would get the same percentage but with 50/50 chance of being "repairable"
What do you think?

[Skubber]

I would really like the chance to repair some of the breakdowns/ sabotage damages. That seems the most realistic to me.

I agree with the earlier poster that the occurence of actual sabotage was probably quite low. (Where as the fear of it was probably considerably higher.)

[Sailor Steve]

I voted for malfunctions but not sabotage. I'm with U-Schulz: I don't know how much sabotage actually went on, but it seems to me that sabotage would cause problems that might prevent you leaving port in the first place.

I've already been told that it's not possible to to have total breakdowns that can be repaired, but I have to dream.

[HEMISENT]

I voted for malfunctions but not sabotage. I'm with U-Schulz: I don't know how much sabotage actually went on, but it seems to me that sabotage would cause problems that might prevent you leaving port in the first place.

I've already been told that it's not possible to to have total breakdowns that can be repaired, but I have to dream.

Hi Steve
If you can, pick up a couple books about the U 505. If I recall correctly this boat was considered a bad luck boat as it left port, started it's patrol and had to return so many times that the crew was accused of cowardice.
I've always been interested the this boat because I live right outside Chicago and have visited it repeatedly as I grew up. Anyway,This is what got me thinking about the concept originally.

As for the real life percentages-I don't know. I tried to pick something that seemed to work for me. Too few (2-5% and you never see any reason to install it, Too much 50% and it gets old real fast-but keep in mind that after 1945 everything was going to hell for the Germans real fast. I attempted to simulate that behavior. With the way Commander is structured you can pick whatever you desire. Same as the actual settings themselves-infinitely adjustable and you don't need the Mini-Tweaker to do it either.

[Sailor Steve]

Good points. It's just that I looked at the original version, and I thought it was too much as well as not covering the early periods.

Maybe the combined version is the right way to go. On the other hand, unless you found gum in the fuel lines how would you know. It's like Thomsen in the longest version of Das Boot talking about his torpedo failures: "Sabotage. You can be sure of it!".

Honestly, I don't know the answers.

[irish1958]

If I were to risk life and limb to sabotage something, I would pick something that really made a difference, and wouldn't be readily fixed, especially at sea. That would mean a severe engine failure, on inability to close an outside hatch, or something that would make the boat sink or not be able to continue it's patrol. So I don't think the sabotage should be repairable at sea and ideally should make the boat more vunerable to enemy attack.
As for malfunctions, probably most of them should be fixable, but not all, and they mostly should just reduce your effectiveness or increase your vunerability. As Jaeson points out, this forces you to make a choice as to continue or turn back. More choices!!!
As the files are easily disabled, I would vote to have the complete package, and then disable what I don't want.
Since the files are tweakable in the SH3CMDR, instructions should be written so a monkey can do it. I would test this function on a few computer illiterate persons to see if they can be followed. I'll volenteer for this; or better yet have my wife do it.
Future mods (i.e. Chaos) should be packaged to install easily and not screw up the programs installed (thermal layers, malfunctions, sabotage, player added random events, etc.) Along this line, would it be possible to have several seperate random folders so that when you have randomized an event and are satisfied with it, new additions would be added to a different random folder.
How about a JSGME for SH3CMDR?
irish1958

[HEMISENT]

If I were to risk life and limb to sabotage something, I would pick something that really made a difference, and wouldn't be readily fixed, especially at sea. That would mean a severe engine failure, on inability to close an outside hatch, or something that would make the boat sink or not be able to continue it's patrol. So I don't think the sabotage should be repairable at sea and ideally should make the boat more vunerable to enemy attack.
Most of the items affected are pretty substantial in varying degrees so yes they pretty much make the boat extra vulnerable to the enemy. As far as not being repairable-you would be surprised what a good chief engineer can come up with. Never say never. However, I will contact Jaesen jones about the idea of splitting the Sab files as I outlined above-after thinking about it a bit it makes good sense.


Future mods (i.e. Chaos) should be packaged to install easily and not screw up the programs installed (thermal layers, malfunctions, sabotage, player added random events, etc.)

The way Randomized events.CFG is set up it's simply a copy/paste affair.
Once Gouldjg wraps up Chaos and releases it the player simply pastes it into the existing Randomized events.CFG. It will not affect the existing structure unless the new mod uses one of the same files as an existing one. And there is a simple method for dealing with that situation also.


Along this line, would it be possible to have several seperate random folders so that when you have randomized an event and are satisfied with it, new additions would be added to a different random folder.
How about a JSGME for SH3CMDR?
irish1958

Yes, multiple Randomized events.CFG are possible-right now I've got 5 in the test version. As far as JSGME for Commander goes-I'm the wrong one to ask, you need to contact Jscones

[JScones]

Here's a thought-I suppose I could just duplicate each file and re name them 0_data (mid patrol), 1_data(no mid patrol), etc. Then increase the Number in the choose from= line to control the odds.
This way the player would get the same percentage but with 50/50 chance of being "repairable"
What do you think?
Yes. Only thing that comes to mind is that one "fix" may be replaced with another "break" when the patrol is re-loaded. Would this be a problem for people?

[JScones]

Since the files are tweakable in the SH3CMDR, instructions should be written so a monkey can do it.
Hemisent, how helpful are the instructions in the header of randomised events file? Does something more detailed need to be written?

I would test this function on a few computer illiterate persons to see if they can be followed. I'll volenteer for this; or better yet have my wife do it.
Randomised events already exists in SH3Cmdr R2.5 - you can have a play around with it if you like and let me know your feedback/suggestions/comments. They will frame how more detailed the instructions need to be.

Future mods (i.e. Chaos) should be packaged to install easily and not screw up the programs installed (thermal layers, malfunctions, sabotage, player added random events, etc.) Along this line, would it be possible to have several seperate random folders so that when you have randomized an event and are satisfied with it, new additions would be added to a different random folder.
How about a JSGME for SH3CMDR?
I'm wanting to avoid that. The problem is, in one sense I've created something that could very easily get out of control. Not sure how to temper that without crippling flexibility.

[JScones]

Future mods (i.e. Chaos) should be packaged to install easily and not screw up the programs installed (thermal layers, malfunctions, sabotage, player added random events, etc.)

The way Randomized events.CFG is set up it's simply a copy/paste affair.
Once Gouldjg wraps up Chaos and releases it the player simply pastes it into the existing Randomized events.CFG. It will not affect the existing structure unless the new mod uses one of the same files as an existing one. And there is a simple method for dealing with that situation also.
Another suggestion: The prefix used before the : can be anything you like. It's sole purpose is to keep section names distinct. I've always suggested just numbers because they're easiest to implement to ensure distinctness. But you could use something like "HM0:data\..." (as in Hemisent's Malfunctions"), or "Hemisent0:data\..." or whatever. Conversely, Gouldjg could use "CHAOS0:data\...". Thus no conflicts when merging different files together.

[irish1958]

I have messed around with the random folder and I think I have the hang of it. I wanted to add a random fanfar and I searched my music files and came up with about 40. I added them to the random folder this way:
I have 52 subfolders in the random folder;
when I open one (Say #2) I get a sub folder Date
when I open that, I have two subfolders: 1) Hemisent's sabotage folder, 19440601 with its subfolder data/submarine/four subfolders;
2)my subfolder 19390901/data/sound/fanfar.
My question is: since the sabotage mod used 52 folders, do i have to repeat this in all 52 folders to get my fanfars to randomize, or could I have added five or six additional folders with just my fanfar files?
I repeated this in the 52 folders 0,1,2,3...52.
Is it possible to have a seperate random folder for each mod, or does one have to use the above method? Since the sabotage mod used 52 folders to make the odds correct, wouldn't my adding seperate folders screw up the odds? If so,I would be limited to the 52 folders.
irish1958

[JScones]

With SH3Cmdr R2.6, Hemisent's sabotage/malfunctions mod will not use the Random folders, thus you will not be not tied to using 52 folders.

But assuming you do have 52 Random folders for whatever reason, you'd add your fanfar files into the existing 52. As you only have 40 files, you can either:

a) leave 12 folders empty of fanfar files in which case if the folder is selected the stock SH3 file will play
b) duplicate some of your fanfar files into the remaining 12 folders.

Using this method you can blend multiple random mods together.

[irish1958]

Thanks, Jaeson.
I think I have it now.
irish1958

[HEMISENT]

Here's a thought-I suppose I could just duplicate each file and re name them 0_data (mid patrol), 1_data(no mid patrol), etc. Then increase the Number in the choose from= line to control the odds.
This way the player would get the same percentage but with 50/50 chance of being "repairable"
What do you think?
Yes. Only thing that comes to mind is that one "fix" may be replaced with another "break" when the patrol is re-loaded. Would this be a problem for people?

Yes I'm finding that now, I really don't know the answer except to drastically increase the odds. Drastically increasing the odds then gives the feeling that you never see anything happening-too subtle/why did I install the mod in the first place. I wonder if this is something that should:
A. Be left as repairable mid patrol for the not so hard core users.
B. Let the hard core guys modify it to their individual liking-most will be able to make adjustments to satisfy their individual tastes plus with good instructions included the needed changes really aren't that difficult.

[HEMISENT]

Since the files are tweakable in the SH3CMDR, instructions should be written so a monkey can do it.
Hemisent, how helpful are the instructions in the header of randomised events file? Does something more detailed need to be written? .

My personal opinion is that they need to be simplified a great deal as not everyone can understand all the symbolism used by those for more computer knowledgable. To be honest, the only reason I have been able to get this far is because of all the numerous back and forth PM's between yourself, Gouldjg and me. Plus the many, many posts on different threads that you have responded to. Keep in mind that Gouldjg and I are really the only ones that I am aware of to have delved into randoms from the beginning with a whole lot of assistance from you we're making great progress.
In the end the procedure itself is simple but understanding the proper format is the key.
I have a file containing all the posts and examples from the beginning that I use to keep things clear.
I believe a user friendly tutorial is badly needed and with your new randomization process it's needed more than ever.
If you want to after the initial release of 2.6 I would be glad to help with a tutorial at least with the random examples I already have on file.

[HEMISENT]

Another suggestion: The prefix used before the : can be anything you like. It's sole purpose is to keep section names distinct. I've always suggested just numbers because they're easiest to implement to ensure distinctness. But you could use something like "HM0:data\..." (as in Hemisent's Malfunctions"), or "Hemisent0:data\..." or whatever. Conversely, Gouldjg could use "CHAOS0:data\...". Thus no conflicts when merging different files together.

That's right, I forgot this part. To avoid confusion down the road (especially with Chaos coming soon) would you suggest I re-name Malfunctions/Sabotage before I send you the final drafts. Something simple like MAL0:data, MAL1:data etc.
Please advise as I just finished the XXI boats and I'm doing final testing tonight before sending the latest merged set to you

[JScones]

Here's a thought-I suppose I could just duplicate each file and re name them 0_data (mid patrol), 1_data(no mid patrol), etc. Then increase the Number in the choose from= line to control the odds.
This way the player would get the same percentage but with 50/50 chance of being "repairable"
What do you think?
Yes. Only thing that comes to mind is that one "fix" may be replaced with another "break" when the patrol is re-loaded. Would this be a problem for people?

Yes I'm finding that now, I really don't know the answer except to drastically increase the odds. Drastically increasing the odds then gives the feeling that you never see anything happening-too subtle/why did I install the mod in the first place. I wonder if this is something that should:
A. Be left as repairable mid patrol for the not so hard core users.
B. Let the hard core guys modify it to their individual liking-most will be able to make adjustments to satisfy their individual tastes plus with good instructions included the needed changes really aren't that difficult.
Maybe A to attempt to appease more people (hah!). Instructions to change for others may be helpful.

[JScones]

Since the files are tweakable in the SH3CMDR, instructions should be written so a monkey can do it.
Hemisent, how helpful are the instructions in the header of randomised events file? Does something more detailed need to be written? .

My personal opinion is that they need to be simplified a great deal as not everyone can understand all the symbolism used by those for more computer knowledgable. To be honest, the only reason I have been able to get this far is because of all the numerous back and forth PM's between yourself, Gouldjg and me. Plus the many, many posts on different threads that you have responded to. Keep in mind that Gouldjg and I are really the only ones that I am aware of to have delved into randoms from the beginning with a whole lot of assistance from you we're making great progress.
In the end the procedure itself is simple but understanding the proper format is the key.
I have a file containing all the posts and examples from the beginning that I use to keep things clear.
I believe a user friendly tutorial is badly needed and with your new randomization process it's needed more than ever.
If you want to after the initial release of 2.6 I would be glad to help with a tutorial at least with the random examples I already have on file.
Yeah, but remember, you started from scratch and blazed the trail (in a way, you even started before I wrote the functionality!). Everyone else now has yours and gouldjg's lead and examples to go by. So that should make it a bit easier for others.

But I would love for you to help with the tutorial. :yep:

[JScones]

Another suggestion: The prefix used before the : can be anything you like. It's sole purpose is to keep section names distinct. I've always suggested just numbers because they're easiest to implement to ensure distinctness. But you could use something like "HM0:data\..." (as in Hemisent's Malfunctions"), or "Hemisent0:data\..." or whatever. Conversely, Gouldjg could use "CHAOS0:data\...". Thus no conflicts when merging different files together.

That's right, I forgot this part. To avoid confusion down the road (especially with Chaos coming soon) would you suggest I re-name Malfunctions/Sabotage before I send you the final drafts. Something simple like MAL0:data, MAL1:data etc.
Please advise as I just finished the XXI boats and I'm doing final testing tonight before sending the latest merged set to you
Yes. That would be great.

[JScones]

BTW Hemisent, check your PM. ;)

[HEMISENT]

Just another thought on mid patrol repairs.
As it stands right now the Sabotage/Malfunctions categories are:

Snort extend time
Periscope optical effects
Flak guns
Radar
These 4 are miscellaneous files

Then there are 2 sub files:
NSS_UboatXX.CFG
NSS_UboatXX.SIM

Right now they are mostly repairable mid patrol. What do you think about
having the one category or the other non repairable. That may strike a balance between the two sides of the discussion.

[HEMISENT]

Another suggestion: The prefix used before the : can be anything you like. It's sole purpose is to keep section names distinct. I've always suggested just numbers because they're easiest to implement to ensure distinctness. But you could use something like "HM0:data\..." (as in Hemisent's Malfunctions"), or "Hemisent0:data\..." or whatever. Conversely, Gouldjg could use "CHAOS0:data\...". Thus no conflicts when merging different files together.

That's right, I forgot this part. To avoid confusion down the road (especially with Chaos coming soon) would you suggest I re-name Malfunctions/Sabotage before I send you the final drafts. Something simple like MAL0:data, MAL1:data etc.
Please advise as I just finished the XXI boats and I'm doing final testing tonight before sending the latest merged set to you
Yes. That would be great.

I'll do that tonight. Along with any last minute changes. Other than that I'm just re-testing the XXI boat in different years then they're done.

[HEMISENT]

BTW Hemisent, check your PM. ;)

Nothing there.

[JScones]

Right now they are mostly repairable mid patrol. What do you think about
having the one category or the other non repairable. That may strike a balance between the two sides of the discussion.
Hehe. I never save mid-patrol (and hence never have save game problems incidently ;)), so I'm prolly not the best person to ask.

But FWIW I don't know about compromising that way. I'd think there would be some items which could not be fixed mid-patrol (periscope, snorkel, maybe even radar?) and there'd be some that could (engines?). I think the equipment and type of damage is what should determine what gets fixed mid-patrol and what doesn't.

Prolly not the answer you wanted though... :)

[JScones]

BTW Hemisent, check your PM. ;)

Nothing there.
:hmm: Well the message just went from outbox to sentbox, so it went somewhere. I'll resend it. Maybe it got "stuck" somewhere.

[irish1958]

You guys are great. I get as much satisfaction from reading your note on your quest to develop and impliment a concept as I do from playing the game.
"Keep up the good work"
irish1958

[HEMISENT]

Right now they are mostly repairable mid patrol. What do you think about
having the one category or the other non repairable. That may strike a balance between the two sides of the discussion.
Hehe. I never save mid-patrol (and hence never have save game problems incidently ;)), so I'm prolly not the best person to ask.

But FWIW I don't know about compromising that way. I'd think there would be some items which could not be fixed mid-patrol (periscope, snorkel, maybe even radar?) and there'd be some that could (engines?). I think the equipment and type of damage is what should determine what gets fixed mid-patrol and what doesn't.

Prolly not the answer you wanted though... :)

Ok, in the interest of actually finishing something and to avoid driving each other absolutely batty along with the realization that you can't please all the people all the time.
A. I'm making all the misc files non-repairable mid patrol.
B. Will also change name prefix on :data files as agreed above.

BTW. So far XXI boat is testing out ok. I never play with it so it's kind of neat tinkering with different systems. Players should be advised that XXI boats are extremely high percentage of Malfunctions due to new construction techniques, parts availability, rushed/poor workmanship etc.

[HEMISENT]

Jaesen
Check your E mail. Merged Malfunctions/Sabotage sent.
Please advise.

[JScones]

Got 'em. Can you pls do me a favour and email the final versions of all your files - both combined malfunctions/sabotage and separate?

Thx.

[HEMISENT]

Got 'em. Can you pls do me a favour and email the final versions of all your files - both combined malfunctions/sabotage and separate?

Thx.

No problem, I need to do a little bit of sorting out first and bring over all the changes from the merged set and make sure they all jive.
Hopefully will get them to you tonight.

Reminder, please take a look specifically at the Schnorkel and Crash depth randomized defaults.

[JScones]

Hehe. Just re-read what I wrote. Of course you don't need to resend me the merged files that you did just send me! ;)

[HEMISENT]

Hehe. Just re-read what I wrote. Of course you don't need to resend me the merged files that you did just send me! ;)

Ok, I get it. :doh: I think I'm getting a bit verklempt here.
I'm going to send the the seperate individual year malfunctions Randomized events.CFG including 1945 just in case you decide to offer the
option as seperate.
Keep in mind that in the Merged set Sabotage files take the place of Malfunctions starting 19440601

[Myxale]

This mod sounds so hard-rock...can't wait.
Finally there will be a"real" reason to test dive your boot and all the other functions!
A real plus there! :rock: :up:

[HEMISENT]

This mod sounds so hard-rock...can't wait.
Finally there will be a"real" reason to test dive your boot and all the other functions!
A real plus there! :rock: :up:

Actually I've been playing/testing misc careers using different years/boats and as it's playing out test diving the boat is a necessity especially when the default 70m depth is no longer valid-some files are set where the boat heads right to 300m if your not watching. Now you need to plan your route and check in with the nav to be sure the range is there. Lots of little things, many of which are very subtle but enough to get you killed if you're not aware. Also, it seems the idea of making some problems repairable mid patrol and some not also is working. Keep in mind this is the first version using Jscones' dated randomization. I'm sure there will be a few edits needed here and there.

Cheers!

[Myxale]

I really love the Idea behind this! Many sources indicate that sometimes a Boot left the drydock to early ...leaving the patroling crew with technical problems in mid patrol.
Finally i also have a good reason to be friendly to my Herr LI. ;)

How do you indend to mix the Sabotage/Malfinction ratio! :hmm:
I read lot about technical problems of rushed Boot's, but nothing on Sabotage!

[JScones]

I must say, I have now had a good close look at what Hemisent has done. It is truly awesome. :up: I intend doing some detailed testing in-game tonight. :D

Based on feedback, I've decided that SH3Cmdr will use the malfunctions settings only by default. These will be contained in:

Randomised events_1939.cfg
Randomised events_1940.cfg
Randomised events_1941.cfg
Randomised events_1942.cfg
Randomised events_1943.cfg
Randomised events_1944.cfg
Randomised events_1945.cfg

However, "Randomised events.cfg" will contain the combined malfunctions/sabotage settings. So, all users will need to do to get the combined settings is delete or rename the above yearly files.

This will be outlined in the readme, but what it means is that SH3Cmdr will ship with both options, so you can choose the one you want without needing to d/l anything else.

Thanks everyone for voting and commenting. As I've said before, it is *your* feedback that has made SH3Cmdr what it is today.