[TEC] SH5.exe patches to fix bugs and add functionality

[Vanilla]

Originally Posted by TheDarkWraith

it doesn't dictate the shaft's RPM but it does play a part in it somehow Just watched it from external cam. Changed the cyan value to half what it was and speed didn't drop to half it's value (sub's actual speed) but only dropped a few knots. Shaft RPM changed considerably though.

That is very weird! My guess is that this code determines RPM + RPMs effectiveness in terms of speed, this means that we doesn't see the whole algorithm but just some random bit of it.

[TheDarkWraith]

Originally Posted by Vanilla

That is very weird! My guess is that this code determines RPM + RPMs effectiveness in terms of speed, this means that we doesn't see the whole algorithm but just some random bit of it.

I have more data on this....but I ran into something really juicy that I had to follow so I'll come back to this later.

Now for the juicy thing: I was looking for something that would point me to where all the dials were updated. After some poking around I found some code that iterates over all the dials (only way I knew I found it is because the loop counter variable on the stack was continually compared against the number of dials on every iteration). I was then able to see the size of each dial in bytes and how the game accesses them (really simple - loop counter variable X each dial size + pointer to start of dials = current dial). Then I traced down everything accessing the dial's base address and mapped it out. The ScriptManager provided the dials enumeration so I knew how to find a particular dial. Now I'm watching to see where in the code it's resetting some of the TDC dials to 0 when you use the stadimeter

[Dignan]

Originally Posted by TheDarkWraith

I have more data on this....but I ran into something really juicy that I had to follow so I'll come back to this later.

Now for the juicy thing: I was looking for something that would point me to where all the dials were updated. After some poking around I found some code that iterates over all the dials (only way I knew I found it is because the loop counter variable on the stack was continually compared against the number of dials on every iteration). I was then able to see the size of each dial in bytes and how the game accesses them (really simple - loop counter variable X each dial size + pointer to start of dials = current dial). Then I traced down everything accessing the dial's base address and mapped it out. The ScriptManager provided the dials enumeration so I knew how to find a particular dial. Now I'm watching to see where in the code it's resetting some of the TDC dials to 0 when you use the stadimeter

I wait with cautious optimism this is still one of my biggest complaints about the tdc

[TheDarkWraith]

Originally Posted by Dignan

I wait with cautious optimism this is still one of my biggest complaints about the tdc

this is one of the biggest bugs in SH5 next to the mast height bug. How these made it through QA is beyond me

I'm also looking into the mast height bug.

@gap - looks like I found a way to call functions in other dlls easily. I found a function in ScriptManager that allows the assembly code to 'fire' a command to all the loaded scripts. The loaded scripts can easily catch this command. The 'fired' command allows you to pass parameters with it also. The scripts can also 'fire' commands to the game passing arguments also. This is excellent because I can write code in C# (hell of a lot easier) to read in your idea your group is working on. A script can load this DLL and communicate with it (again much easier writing Python than assembly!). The script updates the game (and whatever assembly code I write for your idea) by sending new command(s) (whatever I name them) to the game. The game won't understand the commands and will ignore them because it only recognizes what is hard coded in so it will pass them to my command parser assembly code who will divy it out to the correct function. That function will read in the arguments passed with the command and do whatever it needs to do with them. If the function needs to send data back to the script it 'fires' off a command passing the needed information with the command. The script intercepts this command reads the data. Cycle repeats if necessary.

I'm still figuring out how to 'fire' commands using the ScriptManager correctly. I can 'fire' commands no problem, the problem is I don't understand how the parameters for the command are created (something with ScriptManager again) and finally attached to the command (ScriptManager again). Once I figure that out two way communication between game and external DLL via script will be a snap and will open the door up for more opportunities If I can write code for the game in C# I can a) be much faster at it and b) do MUCH more because it's easier to code in C#

Ran into another juicy thing I couldn't turn down - how to access all the menu items in game (think menu editor). I mapped it out and now have the ability to access any menu item and change it. The great thing is while decoding this most of all the pieces of the puzzle I was missing finally fell into place. I couldn't figure out how the game organizes everything. Was everything in a continual linked list? Where there multiple linked lists? Those questions baffled me. I now know that it's a tree structure with each limb of the tree a linked list. Each linked list item can point to another linked list (a limb of that limb - a child). Everything needed to render/update/etc. is contained in each linked list item via pointers. There are tables of function pointers and each table corresponds to rendering, updating, etc. The game just iterates over the tree, accessing each table, and calling functions in those tables. If a feature is not available the entry in the table will call a function that simply returns back to the caller. Actually pretty typical design with a few enhancements.

[Tonci87]

Originally Posted by TheDarkWraith

this is one of the biggest bugs in SH5 next to the mast height bug. How these made it through QA is beyond me

I'm also looking into the mast height bug.

@gap - looks like I found a way to call functions in other dlls easily. I found a function in ScriptManager that allows the assembly code to 'fire' a command to all the loaded scripts. The loaded scripts can easily catch this command. The 'fired' command allows you to pass parameters with it also. The scripts can also 'fire' commands to the game passing arguments also. This is excellent because I can write code in C# (hell of a lot easier) to read in your idea your group is working on. A script can load this DLL and communicate with it (again much easier writing Python than assembly!). The script updates the game (and whatever assembly code I write for your idea) by sending new command(s) (whatever I name them) to the game. The game won't understand the commands and will ignore them because it only recognizes what is hard coded in so it will pass them to my command parser assembly code who will divy it out to the correct function. That function will read in the arguments passed with the command and do whatever it needs to do with them. If the function needs to send data back to the script it 'fires' off a command passing the needed information with the command. The script intercepts this command reads the data. Cycle repeats if necessary.

I'm still figuring out how to 'fire' commands using the ScriptManager correctly. I can 'fire' commands no problem, the problem is I don't understand how the parameters for the command are created (something with ScriptManager again) and finally attached to the command (ScriptManager again). Once I figure that out two way communication between game and external DLL via script will be a snap and will open the door up for more opportunities If I can write code for the game in C# I can a) be much faster at it and b) do MUCH more because it's easier to code in C#

Ran into another juicy thing I couldn't turn down - how to access all the menu items in game (think menu editor). I mapped it out and now have the ability to access any menu item and change it. The great thing is while decoding this most of all the pieces of the puzzle I was missing finally fell into place. I couldn't figure out how the game organizes everything. Was everything in a continual linked list? Where there multiple linked lists? Those questions baffled me. I now know that it's a tree structure with each limb of the tree a linked list. Each linked list item can point to another linked list (a limb of that limb - a child). Everything needed to render/update/etc. is contained in each linked list item via pointers. There are tables of function pointers and each table corresponds to rendering, updating, etc. The game just iterates over the tree, accessing each table, and calling functions in those tables. If a feature is not available the entry in the table will call a function that simply returns back to the caller. Actually pretty typical design with a few enhancements.

Wow, just wow.

You are really a master at reverse engineering.

[TheDarkWraith]

Originally Posted by Dignan

I wait with cautious optimism this is still one of my biggest complaints about the tdc

No more cautious optimism needed...I did it and more

I'll have 2 new patches coming here soon. One fixes the broken stadimeter problem (the mast height always being 20.0) and the other one fixes the problem with the TDC AOB and Speed dials being reset to 0 when you use the stadimeter The nice thing about the second patch is switching TDC dials out of auto mode and back to manual mode (or vice versa) causes no dial jumping or movement (as long as TDC is on)

[THE_MASK]

This game just got a whole lot better

[TheDarkWraith]

v1.0.79.0 released. See post #1

Starting with v1.0.79.0 added two new patches to the SH5.exe: broken stadimeter fix and a patch that fixes the problem of the TDC AOB and Speed dials resetting when TDC is on and stadimeter is used

The broken stadimeter fix patch will use the mast height data specified in the unit's .cfg file.

For those of you using my UIs mod I will be releasing an updated version here soon. The reason is because of these new patches I can remove many items from the mod and free up memory for other things With these patches enabled do not press the red buttons on the AOB or speed dials anymore. They are not to be used and will be removed in updated version

Finally two of the biggest bugs of the game have been squashed

[Sartoris]

Amazing!

Thank you, TDW, you're a miracle worker!

[BigWalleye]

TDW, you da man! Nothing more frustrating than fixing someone else's crappy code. Never tried to do it on a disassembled version, but that must be ten times worse! Thanks for all your hard work.

long live TDW

[TheDarkWraith]

Here's something interesting I found in the exe:

HideParticlesNearView:
"Activate/deactivate with Ctrl+P (in order to avoid NVIDIA problem)"

I never recall having any problems and I have an nVidia card

[Dignan]

Awesome! Can't wait to try it.

[Cthulhus]

Hello,

I have a small problem, I install and patched all files for GenericPatcher (the 4 s5p files like TDW_SH_NClient_Patch.s5p).

All patches has been applied (true) but for the "patch" Close/Open sub doors on Battlestations activated/deactivated (ability - F7 key).

That CTD the game ...

What's is wrong ?

Thanks for your help guys and keep under water

[Fifi]

Originally Posted by TheDarkWraith

Finally two of the biggest bugs of the game have been squashed

Fantastic! You rocks