SUBSIM: The Web's #1 resource for all submarine & naval simulations since 1997 |
03-28-13, 06:52 AM | #1591 | |
Lieutenant
Join Date: Nov 2006
Location: St. Petersburg, Russia
Posts: 264
Downloads: 72
Uploads: 0
|
Quote:
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. |
|
03-29-13, 05:07 PM | #1592 | |
Black Magic
|
Quote:
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 |
|
03-29-13, 08:59 PM | #1593 | |
Seasoned Skipper
Join Date: Mar 2008
Posts: 698
Downloads: 262
Uploads: 0
|
Quote:
__________________
|
|
03-30-13, 11:50 AM | #1594 | |
Black Magic
|
Quote:
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. Last edited by TheDarkWraith; 03-30-13 at 12:18 PM. |
|
03-30-13, 12:55 PM | #1595 | |
Samurai Navy
|
Quote:
Wow, just wow. You are really a master at reverse engineering. |
|
03-31-13, 08:57 PM | #1596 | |
Black Magic
|
Quote:
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) |
|
03-31-13, 10:25 PM | #1597 |
Ace of the deep .
|
This game just got a whole lot better
|
04-01-13, 01:29 AM | #1598 |
Black Magic
|
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 |
04-01-13, 05:56 AM | #1599 |
Captain
Join Date: May 2011
Posts: 489
Downloads: 106
Uploads: 0
|
Amazing!
Thank you, TDW, you're a miracle worker! |
04-01-13, 06:30 AM | #1600 |
Sea Lord
|
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.
|
04-01-13, 06:30 AM | #1601 |
Stowaway
Posts: n/a
Downloads:
Uploads:
|
long live TDW
|
04-01-13, 09:48 AM | #1602 |
Black Magic
|
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 |
04-01-13, 01:57 PM | #1603 |
Seasoned Skipper
Join Date: Mar 2008
Posts: 698
Downloads: 262
Uploads: 0
|
Awesome! Can't wait to try it.
__________________
|
04-01-13, 03:17 PM | #1604 |
Planesman
Join Date: Jan 2002
Location: Bordeaux, France
Posts: 191
Downloads: 136
Uploads: 0
|
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
__________________
Xavier Jehl - Bordeaux |
04-01-13, 03:28 PM | #1605 |
Navy Seal
|
Fantastic! You rocks
__________________
|
|
|