Realism- and gameplay-related hardcode fixes for SH3.EXE

[h.sie]

please describe the "lazy helmsman bug".....

[makman94]

Originally Posted by h.sie

please describe the "lazy helmsman bug".....

hello H.Sie ,

i think he means this time delay that officers have at executing orders.
would be very nice (if it is easy 'fix') to make them execute immediatelly (especially the rudders orders time delay is very annoying)

also, have a look , (if it easy to find out) to make the boat turning at the ordered new course (it is ending with 1 to 1,5 degrees off most of the times)

[Kaleun Cook]

please describe the "lazy helmsman bug".....

I had to search the forum to find out what was meant and found this:
http://www.subsim.com/radioroom/showthread.php?t=182071

Originally Posted by panzerschutze12ss

With the advent of patching the SHIII.exe file. Is it possable to be able to fix the lazy Helmsman now? As we know if you are navigating for a long distance without the using of the the ploting waypoint tool in a storm your helmsman is unable to keep his course. He will just sit there and let your boat drift off coures to nowhere (till he hits the English coast). Now in real life the boat will drift or slip do to the currents (not modeled in SHIII). But the helmsman would still keep you moving in the right direction. Could this be fixed now. It has been awhile since I played SH4 but my memory recalls that you did not have this problem in stormy seas, in fact the exact oposite in that the sub was on rails and never drifted of coures. Now that is not realistic either but i would take that over what we have now.

[h.sie]

I not seldom get requests via PM to mod some graphical stuff and my answer is NO. In order to give you an impression how hard this would be in assembler, I decided to post the assembler sources that are necessary for a simple graphical fix: Move the Watch Officer up to the bridge when surfacing. Maybe you understand now why I'm not cooperative.

//---------------------------------------------------------------
// Patch 7:
// Automatically move 1WO on bridge when surfacing
//---------------------------------------------------------------
patch7:
cmp byte ptr [Move1WO_Switch],0FF // Test Patch ON/OFF switch
jne patch7_ende

// Local Definitions / Pointers
define(Bridge_Status,05f6270)
define(Bridge_Data,05f6238)
define(BowQuarters_Status,05f6990)
define(BowQuarters_Data,05f6958)
define(SternQuarters_Status,05f6a74)
define(SternQuarters_Data,05f6a3c)

// Check if Officer-Slot on the bridge changes from invisible
// to visible. Only in this case: Try to move 1WO to the bridge
mov eax,[5449B0] // Prepare ptr to OfficerSlotBridgeVisible
mov eax,[eax+100] // Prepare ptr to OfficerSlotBridgeVisible
mov eax,[eax+1D38] // Prepare ptr to OfficerSlotBridgeVisible
mov bh,[eax+8C] // Load OfficerSlotBridgeVisible -> BH
mov bl,[OfficerSlotBridgeVisible_Old] // Load old value -> BL
mov [OfficerSlotBridgeVisible_Old],bh // Save current value as old value
cmp bx,0100 // Change from invisible to visible ??
jne patch7_ende // If not: exit patch

// OfficerSlotBridgeVisible changed from invisible to visible.
// First test if Officer Slot on bridge is empty.
cmp [Bridge_Status],(int)-1 // Is Officer Slot on bridge is empty?
jne patch7_ende // If not: exit patch

// Check if Turm damage is < 0.9 (Observations showed that Turm damage can
// be accessed via one of the following 2 pointers:
// Ptr1: Static=5547D4 Offsets: 4,14,14 OR
// Ptr2: Static=5547D4 Offsets: 14,14.
// If the difference of the 2 addresses referenced by these 2 pointers is
// smaller that 0x1000, then (according to observations), Ptr1 is the
// correct pointer, otherwise Ptr2.
mov eax,[5547D4] // Prepare Ptr1 and Ptr2
mov ebx,[eax+4] // Prepare Ptr1
mov ebx,[ebx+14] // Now [ebx+14] holds 1st possible address of Turm damage (Ptr1)
mov ecx,[eax+14] // Now [ecx+14] holds 2nd possible address of Turm damage (Ptr2)
// Now calculate eax = abs(ptr1-ptr2) = abs([ebx+14]-[ecx+14]) = abs(ebx-ecx)
mov edx,ecx
mov eax,ebx
sub eax,edx
cdq
xor eax,edx // now eax = abs(ptr1-ptr2)
// compare abs(ptr1-ptr2) with 0x1000
cmp eax,01000
jb short patch7_continue
mov ebx,ecx // Use Ptr2 instead of Ptr1
patch7_continue:
// [ebx+14] now holds the correct address of turm damage

fld dword ptr [ebx+14] // Load Turm Damage -> FPU
mov [esp-04],(float)0.9 // Load 0,9 for comparison
fcomp dword ptr [esp-04] // Compare with 0,9
fstsw ax
sahf
jae patch7_ende // If Turm damage >= 0,9 : exit patch
// Now: Officer Slot on bridge is empty and Turm Damage < 0,9

// Check if Bow Quarters contains an Officer
cmp [BowQuarters_Status],(int)-1 // If there is no Officer in Bow Quarters
je short Test_SternQuarters // Check if Stern Quarters contains Officer

// Bow Quarters contains Officer. Move him to the bridge.
mov esi,BowQuarters_Data // ptr to data transfer source -> ESI
mov edi,Bridge_Data // ptr to data transfer destination -> EDI
mov ecx,039 // 0x39 DWORDS to transfer
cld // Increment ESI and EDI after each transfer
repe movsd // Execute data transfer
mov [BowQuarters_Status],(int)-1 // Set Bow Quarters status to "No Officer"
mov [Bridge_Status],0 // Set Bridge status to "Officer present"
jmp short Refresh_Crew_Screen // Refresh Crew Screen if necessary

// Check if Stern Quarters contains an Officer
Test_SternQuarters:
cmp [SternQuarters_Status],(int)-1 // If there is no Officer in stern Quarters:
je short patch7_ende // ... -> exit patch

// Stern Quarters contains Officer. Move him to the bridge.
mov esi,SternQuarters_Data // ptr to data transfer source -> ESI
mov edi,Bridge_Data // ptr to data transfer destination -> EDI
mov ecx,039 // 0x39 DWORDS to transfer
cld // Increment ESI and EDI after each transfer
repe movsd // Execute data transfer
mov [SternQuarters_Status],(int)-1 // Set Stern Quarters status to "No Officer"
mov [Bridge_Status],0 // Set Bridge status to "Officer present"
jmp short Refresh_Crew_Screen // Refresh Crew Screen if necessary

// Refresh Crew Screen if necessary
Refresh_Crew_Screen:
mov eax,[6307BC] // Prepare ptr to current screen ID
cmp [eax+50],030 // Is Crew/Damage Screen visible
jne short patch7_ende // If not: No refresh necessary. Exit
// Crew Screen is visible. Do a refresh by changing to NavMap screen
// and immediately switch back to Crew Screen
mov ecx,[6307BC] // Prepare "Change Screen" call
push 0 // Prepare "Change Screen" call
push 0 // Prepare "Change Screen" call
push 040024 // Choose "NavMap"
call 50fef0 // call "Change Screen"
mov ecx,[6307BC] // Prepare "Change Screen" call
push 0 // Prepare "Change Screen" call
push 0 // Prepare "Change Screen" call
push 040030 // Choose "Crew Screen"
call 50fef0 // call "Change Screen"

patch7_ende:

[Pisces]

Originally Posted by h.sie

please describe the "lazy helmsman bug".....

Originally Posted by Kaleun Cook

I had to search the forum to find out what was meant and found this:
http://www.subsim.com/radioroom/showthread.php?t=182071

Yes, that is it. As soon as the commanded course is achieved (or within some margin) the guy takes the day off. He just won't keep adjusting the rudder to keep the course. After that ownship course is left to the effects of wave-action and what not. Dereliction of duty, I say. Dead-reckoning navigation over long time periods is useless. He constantly homes in on waypoints, but not this. Would be great if you could build a PID-controller in his brain.

[EDIT] Warning, feature creep! With improvements based on experience!?!

[Kaleun Cook]

I think I came across a problem with the new restrictions on external reloading. Riding a IXC I got a bug when I wanted to load external torpedos inside, similar to this old one: http://www.subsim.com/radioroom/show...ernal+torpedos

The torpedos didn't appear in the externals anymore but they weren't loaded inside either. One of them became all black, the other one stayed in the greyish color, and I could drag both around the screen. Also, the weapon screen appeared a tone darker than normal, as if there was an extra "layer" above it.

I remember someone once adviced to just submerge and surface again to get rid of such behaviour - but that wasn't possible with the bugfix because it forbids diving. But I couldn't abort the loading either, maybe because it never had started correctly. So there I was, forced to stay surfaced making 5 knots. I tried to save and reload the game to see if that helps - but of course the game crashed to desktop.

However, this was the first time this happened to me, a lot of external torpedo reloading went well before. The only special thing this time was that I was sitting near a harbor and the game kept popping up "merchant sighted"-messages when I wanted to load the external torpedos inside. Maybe that caused the trouble.

[Jimbuna]

That bug was fixed in GWX2.0

[Kaleun Cook]

Originally Posted by jimbuna

That bug was fixed in GWX2.0

Yet it happened to me with GWX 3.0 in this case.

[Jimbuna]

Originally Posted by Kaleun Cook

Yet it happened to me with GWX 3.0 in this case.

Can't understand why because there would be hundreds if not thousands of similar posts on here.....I can only presume a conflict of mods.

[Kaleun Cook]

Originally Posted by jimbuna

Can't understand why because there would be hundreds if not thousands of similar posts on here.....I can only presume a conflict of mods.

That or maybe the "ship spotted"-interuptions somehow had an influence. My GWX-Mod-List:

GWX - 16km Atmosphere
GWX - Lite Harbor Traffic
GWX - No Medals on Crew
GWX - Open Hatch Mod
M.E.P v3
TheDarkWraith_DC_Water_Disturbance_v4_0_SH3
TheDarkWraith_Ship_Plane_Fire_Damage_v1_4_SH3
Supplement to V15E3_NOSF (JSGME)
GWX 2 - No RING RING Mod by Melendir
M.E.P v3-Patch
M.E.Pv3 VisualSensors-GWX3
Waterstream+Exhaust Combi V2.3 for GWX3
WBs Mission Orders Lite
Wooden_Lifeboats_Mod_1.1
Real Depth Charge
TMTv2+ThomsensShips v4.4 for GWX3+Xtra ships
MaGui F
optional-blue recmanual for MaGui F
optional-stopwatch with speed lines for MaGui F
TorpedoSolutionButton for MaGui F (LSH3) Edit: whoops, exchanged for the correct one now.
Rbs1_SH4_Effects_GWX_30_71
German Images for MaGui F
GWX - Contact Color
Flags_enlighten

Aaaaaand:

Q Ship mod GWX3.0

[h.sie]

@KaleunCook: Can you reproduce the error?

[Kaleun Cook]

I'll try to later this weekend!

[h.sie]

@Kaleun: It is very important to be able to reproduce the error. After that, it would be interesting to see if the CTD occurs with an unmodded sh3.exe.

[h.sie]

Now I need some help from those who use the patches for sh3.exe.

Since I'm now able to generate console messages (e.g. "external topedoes cannot be reloaded in bad waether" or "fog arises, sir"), these messages have to be placed in the de_menu.txt and en_menu.txt.

I discovered that in my GUI, the entries between 4813 and 4899 are not used. But I want to be compatible to all available GUIs. So here's my 2 questions:

1. What GUI do you use?

2. Are entries 4813 to 4899 empty in de_menu.txt / en_menu.txt of your GUI?

Thank you!

[reaper7]

Using Makman94's MaGui Final

Entries are:

de_menu.txt

4812=Bericht konnte nicht gesendet werden!

;Sonar
4900=Horche ...

en_menu.txt

4812=Could not send report!

;Sonar
4900=Sweeping!

So all good there mate