@SSB: That's because I had to make one code section longer to place my routines in it. Some viruses use this mechanism, too, in order to add malicious code to applications and dlls.

I promise that I have not applied any maliciuos code.
But if you don't trust me, simply don't use the mod.

@ALL: In the meantime I changed the 1WO messages:

Range already works (fine) as follows:

Range < 1000m : Messages in 100m steps
Range = 1000m - 3000m : Messages in 200m steps
Range = 3000m - 6000m : Messages in 500m steps
Range > 6000m : Messages in 1000m steps

Bearing will be in 5 degrees steps. Not done yet.

This mod can optionally be switched off for those who play with auto-targeting, because otherwise there is a discrepancy between exact TDC and inaccurate 1WO.

h.sie

O no, you got me wrong, mate.
I'm pretty sure of that.

Just this was my first thought:---------------

Did today a little single mission with massive air attacks to get damaged.
My first impression was that the repair times were much shorter than longer... :hmmm:

Played that mission only for short time [around half an hour], maybe I'm wrong...
I'll check this the next days.

Amazing work, h.sie! :yep: :yep: :yep:

Now only the lazy WO and the CO2 have to be fixed and we are a big step closer to the perfect sim.

Thanks!

Cheers, LGN1

Hi SSB,

I can assure you exact the opposite. The mod works flawless, today i tested the V15A with 60x and 120x: and is just amazing, all works as expected, the tension do try to fix and stop floodings with your boat showing the gravity center deviations by flooding is better than never now. Even better (speaking in final balance of the mod) than the old LRT mod by ndrifter (which I much respect and since early days put all my support on it).

What i noticed (and probably was exactly what you saw) is that sometimes you have really few damage that could continue to be repaired in a minute or two. Take in mind that these were repaired in a second in the stock game.;)

Yes, just incredible. You are a wizard mate!

I just recall about the odd compress air routine used in the game. The compressed air was consumed in RL every time that the uboat go dive and then go up...will be very realistic if we could make it slowing be consumed every time you up a bit after dive.
What you think h.sie? It´s doable?

@SSB,

maybe you looked at the repair times of the COMPARTMENTS. these have not changed, because they are linked to the (fast) flooding time and the recovery of the flooding. but all EQUIPMENT takes 60 times longer to repair now.

oh no, I forgot: if you followed ALL steps of the course, you've surely deleted the patched exe file before playing it and renamed back the original sh3. so you could not see any changes. of course. all behaves as expected.

:DL

@Rubini:

If I were a wizard, I'd programmed my own Subsim. I am even not a good programmer, since I needed 1 whole day to program a floating-point comparison in the FPU. my only quality it to be very persistent .

h.sie

Range & Bearing works very well now. But I've to clean up my spaghetti code and test a little bit (long-time stability).

Next steps on the ToDo List:

1) Move lazy 1WO on bridge when surface.
2) CO2

greetings,
h.sie

@Rubini: Could you please explain more in detail what is the problem with the odd CO2 routine. I never discoverd any problem with CO2 since I never played seriously. So, before programming, I have to become familiar in detail with that problem/bug.

Maybe here is someone with good x86 assembler skills, who could help me. While it is relative simple to do a conditional jump with integers in the CPU registers:

cmp EAX, EBX ; compare registers EAX and EBX
jge dest ; jump to dest if EAX > EBX

I found out that it is relative complex to do the same with floating-point values in the FPU, since one has to assure that FPU and CPU are syncronized:

fcom st(1) ; compare FPU registers st(0) and st(1)
fwait ; wait until FPU is ready (synchronize)
fstsw ax ; copy FPU status word to CPU register AX
fwait ; wait until FPU is ready (synchronize)
sahf ; set CPU flag registers according to AX for conditional jump
ja dest ; jump to dest if st(0) > st(1)

This works, but I don't like it. Is this really the most simple solution for a simple conditional jump??? I cannot believe that. Is the synchronization really necessary?? I cannot imagine that the CPU does not wait for the FPU.

Thanks.
h.sie

P.S: Maybe this is a good example to show my problems in order to damp down any expectations regarding complex addons in the future.

Sorry, h.sie, I cannot help you with the assembler :-?

Concerning Rubini's posts: There are two problems. One is the CO2 buildup in the sub that forces you to surface after some time. That works fine in the sim, the time is just too short (buildup too fast) in my opinion. The other issue is the compressed air usage. Here is an old discussion about it:

http://www.subsim.com/radioroom//sho...d.php?t=163651

Basically, as Rubini wrote in the old thread, it's quite useless in the game. But I have no good idea how to improve it in an easy and realistic way :hmmm: I guess making it more useful is for some future mod (Some open questions: How does the compressed air decrease when you order a new depth? What happens if you use the dive planes? Would a slow continuous decrease (no matter what you do) be realistic?...).

Cheers, LGN1

I just contacted Neal Stevens about this situation. Now waiting for his reply.

The link that LGN1 provided can give you a good idea about the problem.
I guess that the stock game compressed air usage is one of the major drawnback to use Sh3 as a real simulator. It's hardcoded, not possible to mod by common files of the game. Probably your mod will the unique hope here and perhaps doable as it is just one variable, just one aspect of the game.

The idea is to consume the compressed air a bit every time the boat surface or go up a bit from the depth. If we achieve it, then the use of the compressed air will open a new tactical level for Sh3, you will need to take it in mind to make maneuvers, etc. Just as a real Kaleum.

If the hunt of a hook to consume it every time you go up (by hitting S or change the depth up using the dials) shows itself impossible or very difficult to implement then could be better than nothing just to consume the compressed air a bit every time you dive. It's a good compromisse IMHO.;)

The CO2 problem is totally new to me, but it seems to be important for tactical decisions - very interesting. But I need time to get familiar with the problem. I've not yet read the thread LGN1 posted. Until now I thougt, the CO2 gauge only shows the Co2 level in the air to breathe. Nothing more. I thought we have to differenciate between:

• CO2-Level in air: Not good for the crew. They prefer O2 instead.

• Compressed air: Needed for diving/surfacing maneuvres.

It does not seem impossibe to fix, but first I will enhance my programming and debugging skills by automatically pushing the lazy 1WO to the bridge - not a very important thing - but nice to have. h.sie

Yes, that lazy 1WO will be also a very nice touch!:up:

Now more info to try to clear the air matter: the CO2 feature/implementation and the compressed air are totally diferent things and also both have their own dial on game. Fixing one will not mess with the other and so on.

The Co2 fix idea is just to elongate the dive time for crew, putting it at the RL levels.

The compressed air is used to maneuver the boat UP/Emergency surface. And what is broken is that only the emergency surface work now on the game (concerning compressed air consume). If fixed, it will raise a lot the sim feeling of the game.;)

Aaah, ok, that are two different problems. Now I begin to understand.

Just discovered a problem:

While testing I heard:
"Ship Spotted: Bearing 207. Medium Range".

After pressing the Nearest Visual contact button, I can read:
Nearest Visual contact Bearing 205. Range 1500m.

There is a little discrepancy between those 2 messages.

So either I change the first message, too, or I take back the 5 degrees steps for Bearing in my mod.

I tend to take back my changes for bearing since exact Bearing values could surely be done much easier than range values.