Sorted. :up:

Wake up WO... ;)

-----------------------

Maybe your AV Guard prevented that?
I have to send my AV Guard to bed before patching otherwise the files were shredded...

Hey Alex, where've you gone ??? http://img844.imageshack.us/img844/9571/noidea.gif

Didn't follow this a few weeks and I gotta ask is the change once done permanent, ot do i have to apply the fix every time!

Sorry if I'm being dense!:88)

Once done it is permanent.

h.sie,

A small request. Can you move your excellent courses to the first post so we don't need to browse through the thread to find each individually?

that's a very good idea. I'll do that during the next days.

Status changed to [REL] and first post updated. In the future it will contain all news and necessary information. Still trying to automatically move the 1WO to the bridge, but I am pessimistic in the meantime.

Next patch version V15B this weekend, containing more inaccurate range estimations from 1WO.

Excellent, thank you!

Well,if you manage to fix the WO it'll be the cherry on top.

You did some amazing stuff already!:up:

Hi h.sie,

After a lot of tests using your mod and also after a lot of time being depth charged on the U505 mission using both just vanilla game and my slight modded one I started to see, sometimes, my boat going deep and deep even without more flooding inside...it didn´t goes up anymore even using blow ballast or force engines full. It was like an invisible flooding putting my uboat more and more deep...It only happened on my slight modded installation.
Also in others very rare situations my external uboat view (underwater)just showed nothing and the cameras becomes strange (again after suffer heavy depth charge hits)

Trying to find the culprit I finally isolated that old very good mod: Uboat Keel (the one that allow you to stay on the sea floor making repairs without being damaged by the sea floor "collision").

At firtst I could not determine if it´s yours changes on repair time that are making the Uboat_keel mod to have an strange behaviour (perhaps something to do with repair times - it´s a zone compartment in the end) or if this uboat _keel mod is the unique culprit, e.g., it always could have this behaviour but it´s is just too difficult to observe - you need to achieve damage in the kell by depth charges to see this behaviour...

Later i tryed the below modifications on the uboat_keel definitions on zones.cfg and it solve both problems (deep blues and external view disappearing):

The original Uboat_keel zones.cfg definitions:

[UboatKeel]
Multiplier=1.000000
Flotability=0.000000
HitPoints=99999
Destructible=No
Armor Level=99
;Critic Flotation=0.300000
Critical=No
FloodingTime=9999
CargoType=None

Just change for this one:

[UboatKeel]
Multiplier=1.000000
Flotability=0.000000
HitPoints=999999
Destructible=No
Armor Level=9999
Critic Flotation=0.9999999
Critical=No
FloodingTime=99999
CargoType=None

As this solve the problem is clear to me (but not absolutelly sure yet) that it´s an inherent uboat_keel mod problem, its virtual compartiment was suffering small damage when heavily depth charged and probably the parameters aren´t enough well adjusted for this hard situation, bring some invisible flooding and later bring cameras problems when it was "totally" flooded... :up:

Hopes this could help someone more that is also running both mods!

Cheers,

Rubini.

@Rubini,

thanks for sharing this detailed information (which one should keep in mind for the future). I am very sure that my repair time modification does nothing more than enlarge repair times, because it simply changes one factor. nothing more. but of course it changes the gameplay situation when damaged (repairs need more time now and so damage can cumulate). and because of this, now some side-effects of the U-Boat-Keel mod (is it the Seabed Repair Mod from Mikhayl?) which have been invisible so far, now maybe become visible.

But even if that is a bug: it only occurs seldom according to your observation. couldn't it be interpreted as an unforeseen failure of an heavily damaged u-boat for which noone has an explanaition. I think that unpredictability is some kind of realism.

@ALL (who are interested):

Currently I am thinking about 2 things:

1) 1WO - Nearest visual contact: Should I enlarge the range steps to 2000m for ranges > 10000m? This would make long range plotting more inaccurate.
Or are 1000m steps enough inaccurate / more realistic?

2) WP: Should I also try to make the firing solution of the Weapons officer more inaccurate the same way (Weapon Officer / Torpedo attack / Firing Solution). That surely would make sense, although I will play manual targeting without help of Weapon Officer.

But: Changing the WP firing solution could result in too bad firing solutions and so it will need fine-tuning (and many controverse discussions) in the future. and also at the moment I don't know if I can consider the experience / competence of the WP to modify the solution. Another problem is that these changes cannot fit all flavors. For some people they are too inaccurate, for some not. I fear a little bit to make those changes, and since I will not use the WP assistance, it's not worth the effort (for me) and not worth the risks every hardcoded change involves.

h.sie

About the Visual contacs, I'm not sure how this will work with 16km and similar mods.

I would love the inacurate WO firing solution. Together with a reasonable delay after asking for a solution. Always killed the immersion when the WO was able to spout his calculations faster than Einstein!
I use the WO on surfsace attacks for it used to be this way.

But if it opens more cans of worms, then stick to the things at hand first.

There is time for this later.:salute:

@Myxale: It works this way: For ranges > 10000m the range will be displayed in 2000m steps (10000, 12000, 14000, 16000) and not in 1000m steps as my first idea was.

The time delay is a very good point (which automatically can result in a more inaccurate solution). Unfortunately, I have no idea how to implement that in an easy way. After pressing the firing solution button, the according event-handler calls and executes hundreds of routines and subroutines IN SEQUENCE. if I delay one of them, the rest will also pause and wait. that is not possible. the only way around would be to cut the WP-firing-solution-routine out of this sequence, pause and execute it in a special thread IN PARALLEL, so that the other routines don't have to wait. I've done that in C++ and Java but it's impossible for me in assembler without SDK, although the problem seems to be so simple. h.sie

Yes, its exactly the "Seabed Repair Mod" from Mikhayl. And for sure, is just possible to interpret the bug as an unkown uboat damage by heavy session of depth charges...but i find it a bit frequent now that I know how to reproduce it for tests...I'm almost sure that what I found was an unexpected bug of the Seabed Repair mod that probably neither Mikhayl saw it. Anyway the more important is that it is easily fixable as I wrote above.;)

For 1WO I suggest in 1000 steps for long distances, or better: isn't possible to make this estimated distance error a bit random? (as probably in RL?) The same idea (bit random error) could be applyed also for the WP solutions readings?
And finally the delay will be - even if the unique modification for WP readings solutions - a awesome addition. I totally agree with Mixale about it.

Hi Rubini,

the "randomness" is already implicitely contained in the error that results from the discretisation of the range. E.g.

Ship A has real range 977m. 1WO says 1000m. Error: 23m
Ship B has real range 1090m. 1WO says 1000m. Error: 90m
Ship C has real range 1000m. 1WO says 1000m. Error: 0m

and so on. You don't know the ships real range, so the error is random (from your perspective).

Easy to program and effective.

The problem with random numbers is that you can get different results for the same ship when you ask 1WO several times. And also you can get big discrepancies when you compare the range from the 1WO with the firing solution of the WP.

Ok, I will try to make the WP firing solution more inaccurate the same way I did it for the 1WO. Since the numerical values (distance steps: 100m, 200m, 500m, 1000m plus the ranges for these distance steps: 1000m, 3000m, 6000m) can easily be changed in the .exe with an Hex-Editor, fine-tuning of the accuracy can be done later and even individually. One only needs the adresses of the numbers in the .exe.

greetings,
h.sie