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

THE_MASK · 03-26-13, 04:51 PM

I have a ctd on loading a save game with the new rendering patches when i click on the navigation map icon . This save game was a save with all the rendering patches enabled . I just tried disabling one by one and it seems to be the sub rendering patches . Does it have something to do with real navigation ?

TheDarkWraith · 03-26-13, 05:18 PM

Quote:

Originally Posted by sober

I have a ctd on loading a save game with the new rendering patches when i click on the navigation map icon . This save game was a save with all the rendering patches enabled . I just tried disabling one by one and it seems to be the Disables rendering of units except players sub (all the time) . Does it have something to do with sunk ship icons ?

I wondered about that one. Maybe I should remove it from patch list

There are other render patches that do the same thing it did

TheDarkWraith · 03-26-13, 05:33 PM

Here's a question/something to test:

Can you totally drain the batteries? I mean does battery level ever go to 0% and you lose propulsion? Looking at the game code here (just stumbled onto it

) it suggests that if current battery capacity < 0.001 then set current battery capacity to 0.001 thus meaning you can never deplete the batteries fully

Can someone test this and report on it

Fifi · 03-26-13, 05:52 PM

You are right TDW!!

Flank speed underwater, i fall to 2% (and never can go under this value) but speed finally fall to 1 knot...and i can navigate submerged for ever! (unless i have no more CO2)
So batteries never can stop...this is a major bug you have to fix IMO!!

gap · 03-26-13, 05:58 PM

Quote:

Originally Posted by TheDarkWraith

Here's a question/something to test:

Can you totally drain the batteries? I mean does battery level ever go to 0% and you lose propulsion? Looking at the game code here (just stumbled onto it

) it suggests that if current battery capacity < 0.001 then set current battery capacity to 0.001 thus meaning you can never deplete the batteries fully

Can someone test this and report on it

Quote:

Originally Posted by Fifi

You are right TDW!!

Flank speed underwater, i fall to 2% (and never can go under this value) but speed finally fall to 1 knot...and i can navigate submerged for ever! (unless i have no more CO2)
So batteries never can stop...this is a major bug you have to fix IMO!!

Maybe this is a life buoy devs left in the code for us

TheDarkWraith · 03-26-13, 06:14 PM

Quote:

Originally Posted by Fifi

You are right TDW!!

Flank speed underwater, i fall to 2% (and never can go under this value) but speed finally fall to 1 knot...and i can navigate submerged for ever! (unless i have no more CO2)
So batteries never can stop...this is a major bug you have to fix IMO!!

Assembly code doesn't lie

Quote:

Originally Posted by gap

Maybe this is a life buoy devs left in the code for us

Unrealistic. Time to patch this out

I'm looking for a battery drain curve and so far I'm not finding it. Appears devs have simple battery drain - linear. Real life this is an exponential curve where the curve falls off quickly towards the end of the battery's capacity (ex-Navy Nuke EM here

) . Looks like have to code that in if I can't find it also.

gap · 03-26-13, 07:08 PM

Quote:

Originally Posted by TheDarkWraith

Unrealistic. Time to patch this out

I'm looking for a battery drain curve and so far I'm not finding it. Appears devs have simple battery drain - linear. Real life this is an exponential curve where the curve falls off quickly towards the end of the battery's capacity (ex-Navy Nuke EM here

) . Looks like have to code that in if I can't find it also.

some typical charge/discharge curves for lead acid batteries (the ones used on U-boats), in case you needed for them:

http://www.ibt-power.com/Lead_acid_t...cid_tech.html#
http://www.yuasaeurope.com/en-gb/ind.../products/npl/

The graphs available from the above links are relative to modern batteries, indeed, but hopefully they didn't change that mutch since WWII

Fifi · 03-26-13, 07:45 PM

Quote:

Originally Posted by TheDarkWraith

Time to patch this out

Good luck with it! I'm sure you'll offer a nice fix as usual

Luckily you are here

TheDarkWraith · 03-26-13, 08:10 PM

Quote:

Originally Posted by Fifi

Good luck with it! I'm sure you'll offer a nice fix as usual

Luckily you are here

Oh I just stumbled onto a gold mine that I've been waiting to discover

alright put your thinking caps on

Here's the problem: the below defines how the game gets the speed in knots from ordered speed (ordered speed in range -1.0 to 1.0). I can't figure it out

VIIC submerged (12m) with no snorkel so using electric engines. Ordered speed set to 0.1. Current speed is 0 knots:

Loads something dealing with engine into XMM1 (3.913995) <----- what is this number? This number is something dealing with the electric engines
multiplies XMM1 by ordered speed (0.1) - ordered speed in range -1.0 to 1.0
XMM1 now equals 0.3913995
compares 0.0 to XMM1
If after then do something with it - ours is before so it's good
compares XMM1 to 0.0
if before or equal then jump - ours is after so:
loads XMM2 (1.0) into a stack variable
compares XMM0 (0.0) to XMM1
loads XMM1 into XMM0 (XMM0 now equals 0.3913995)
if after then do something - ours is before so it's good
loads constant 0.333333 (1/3) onto top of floating point stack
adds XMM2 (1.0) to XMM0 (0.3913995) thus XMM0 now equals 1.3913995
divides XMM0 by 559500.0 <---- what is this number? This number is something dealing with the electric engines
XMM0 = 2.486862e-06
multiplies XMM0 by 7432.328 <---- what is this number? This number is something dealing with the electric engines
XMM0 = 0.01848318
multiplies XMM0 (0.01848318) by XMM1 (0.3913995)
XMM0 = 0.007234306
multiplies XMM0 (0.007234306) by XMM1 (0.3913995)
XMM0 = 0.002831504
raises XMM0 to the 0.3333333 power (why the 0.3333333 power?)
XMM0 = 0.1414726026023053196
multiplies XMM0 by 30.99133 <---- what is this number? This number is something dealing with the electric engines
XMM0 = 4.3844245387299654350 which is the new speed of the sub in knots
multiplies XMM0 by direction (1.0 = forward, -1.0 = reverse) - we are going forward
saves XMM0 to engine's speed in knots memory address

Anyone make any sense of this

I need to figure this out so I can try and code in something that decreases the engine's efficiency (wear) over time (time being career)

gap · 03-26-13, 08:57 PM

Sorry, I have no idea about those numbers

but I have noticed that in describing the whole process you used often the words before and after as if you were sure that the discussed variables are times. Is it so, or am I misunderstanding your reasoning?

gap · 03-26-13, 09:04 PM

Totally off topic (well, actually the topic is that I finally catched you online

), can you please look at this issue with the twin M42 gun, when you get time for it?

http://www.subsim.com/radioroom/show...postcount=1940

I suspect that the problem could be in some hardcoded gun camera or tooltip assignation, as it only appears when walking close to the gun.

Otherwise the gun works perfectly. If you want, I can send you my files making the gun available as armament upgrade.

TheDarkWraith · 03-26-13, 09:54 PM

Quote:

Originally Posted by gap

Sorry, I have no idea about those numbers

but I have noticed that in describing the whole process you used often the words before and after as if you were sure that the discussed variables are times. Is it so, or am I misunderstanding your reasoning?

Sorry, assembly language speak. When something is TESTed it sets flags in the FLAGS register of the CPU. You can then check those flags to manage execution. In this case two XMM values (for this argument consider them float values) are TESTed. Then the game code checks to see if value 1 is before (<), equal (==), after (>), etc. value 2 and if so execution jumps to some other place.

BigWalleye · 03-27-13, 06:52 AM

Quote:

Originally Posted by sober

I have a ctd on loading a save game with the new rendering patches when i click on the navigation map icon . This save game was a save with all the rendering patches enabled . I just tried disabling one by one and it seems to be the sub rendering patches . Does it have something to do with real navigation ?

What he said. Except that disabling Render Patch 7 does not correct the problem for me. Disabling all render patches does, as does rollback to v1.0.77.0. I have not yet fault-treed the render patches to isolate the cause. Concerned there might be more than one, and did not have time to test all combinations. I will do so later.

Vanilla · 03-27-13, 06:56 AM

1/3 power (cube root) is to give lesser speed increase at greater speed orders. That is - less and less efficiency (speed increase) at greater and greater PS applies. Just look at the plot of the cube root.
NB: Cube root works well both for positive and negative ordered speeds as compared to even roots (that is why it is not square root - 1/2 power).

I will give my full analysis later, I am at it at the moment. My wild guess so far is that it is xmm2 you should tinker with to lower or increase the engine 'efficiency'.

Vanilla · 03-27-13, 08:22 AM

Ok, here is the analysis:

Let's first derive the formula implied in the code:

speed = 30.99133 x cube_root[ (7432.328 / 559500) x (XMM2 + ordered_speed x XMM1) x (ordered_speed x XMM1)^2 ]

or:

speed = 30.99133 x 0.23683266 x cube_root[ (XMM2 + ordered_speed x XMM1) x (ordered_speed x XMM1)^2 ]

We can try to simplify it further but if we just insert this formula into excel/calc we will get to the following values (we drop the negative values since we cannot see what what is done with those from the code excerpt given):

Code:

0             0,00000
0,1          4,38442
0,2          7,55932
0,3          10,58301
0,4          13,54768
0,5          16,48260
0,6          19,40030
0,7          22,30711
0,8          25,20658
0,9          28,10086
1             30,99133

Now we can see that the speed goes way higher than expected max 12 knots. There should be some mechanism that limits either the speed or the orders. My guess that the game actually limits the order by 0,4 this gives 13,6 knots -- close to the max speed.
The other thing to see is that the combination of constants 3.913995 (xmm1) and 7432.328/559500 works so that the max speed at order 1.0 will be equal to the constant given later in the code (30.99133) if we change this number to, say, 20, the speed at 1.0 setting will be also 20 with speeds at other settings changing accordingly (@TDW this can be the answer to your question), at 0.4 setting the speed will be 8.7 knots.
What is puzzling is XMM2 which changes almost nothing. If we set it to 0 the max speed (30.99) will change only by 2 knots to 28 and the speed at 0.4 will be 11.49. Why this xmm2 variable is needed at all?

To put some logic into the formula here is my thinking:

1/3 power (cube root) is used to make the curve that match reduced efficiency at greater power.
The 3.913995 number is the conversion coefficient for either PS or RPMs to knots. That is, for example 'we get 3.913995 knots per each 100 RPMs increase if we assume 100% efficiency.
The 30.99133 is theoretically possible max speed the sub can achieve. (Though it is puzzling why it is so huge? Surface speed with all the upgrades? Still too much).
xmm2 is a puzzle
The 7432.328 and 559500 are there just to balance the equation.

03-26-13, 04:51 PM	#1561
THE_MASK Ace of the deep . Join Date: Jan 2006 Posts: 9,226 Downloads: 901 Uploads: 73	I have a ctd on loading a save game with the new rendering patches when i click on the navigation map icon . This save game was a save with all the rendering patches enabled . I just tried disabling one by one and it seems to be the sub rendering patches . Does it have something to do with real navigation ? Last edited by THE_MASK; 03-26-13 at 05:18 PM.

03-26-13, 05:52 PM	#1564
Fifi Navy Seal Join Date: Dec 2012 Location: France Posts: 5,744 Downloads: 456 Uploads: 0	You are right TDW!! Flank speed underwater, i fall to 2% (and never can go under this value) but speed finally fall to 1 knot...and i can navigate submerged for ever! (unless i have no more CO2) So batteries never can stop...this is a major bug you have to fix IMO!! __________________

03-27-13, 08:22 AM	#1575
Vanilla Lieutenant Join Date: Nov 2006 Location: St. Petersburg, Russia Posts: 264 Downloads: 72 Uploads: 0	Ok, here is the analysis: Let's first derive the formula implied in the code: speed = 30.99133 x cube_root[ (7432.328 / 559500) x (XMM2 + ordered_speed x XMM1) x (ordered_speed x XMM1)^2 ] or: speed = 30.99133 x 0.23683266 x cube_root[ (XMM2 + ordered_speed x XMM1) x (ordered_speed x XMM1)^2 ] We can try to simplify it further but if we just insert this formula into excel/calc we will get to the following values (we drop the negative values since we cannot see what what is done with those from the code excerpt given): Code: 0 0,00000 0,1 4,38442 0,2 7,55932 0,3 10,58301 0,4 13,54768 0,5 16,48260 0,6 19,40030 0,7 22,30711 0,8 25,20658 0,9 28,10086 1 30,99133 Now we can see that the speed goes way higher than expected max 12 knots. There should be some mechanism that limits either the speed or the orders. My guess that the game actually limits the order by 0,4 this gives 13,6 knots -- close to the max speed. The other thing to see is that the combination of constants 3.913995 (xmm1) and 7432.328/559500 works so that the max speed at order 1.0 will be equal to the constant given later in the code (30.99133) if we change this number to, say, 20, the speed at 1.0 setting will be also 20 with speeds at other settings changing accordingly (@TDW this can be the answer to your question), at 0.4 setting the speed will be 8.7 knots. What is puzzling is XMM2 which changes almost nothing. If we set it to 0 the max speed (30.99) will change only by 2 knots to 28 and the speed at 0.4 will be 11.49. Why this xmm2 variable is needed at all? To put some logic into the formula here is my thinking: 1/3 power (cube root) is used to make the curve that match reduced efficiency at greater power. The 3.913995 number is the conversion coefficient for either PS or RPMs to knots. That is, for example 'we get 3.913995 knots per each 100 RPMs increase if we assume 100% efficiency. The 30.99133 is theoretically possible max speed the sub can achieve. (Though it is puzzling why it is so huge? Surface speed with all the upgrades? Still too much). xmm2 is a puzzle The 7432.328 and 559500 are there just to balance the equation.

03-26-13, 05:33 PM	#1563
TheDarkWraith Black Magic Join Date: Jun 2007 Posts: 11,962 Downloads: 147 Uploads: 5	Here's a question/something to test: Can you totally drain the batteries? I mean does battery level ever go to 0% and you lose propulsion? Looking at the game code here (just stumbled onto it ) it suggests that if current battery capacity < 0.001 then set current battery capacity to 0.001 thus meaning you can never deplete the batteries fully Can someone test this and report on it

03-26-13, 08:57 PM	#1570
gap Navy Seal Join Date: Jan 2011 Location: CJ8937 Posts: 8,214 Downloads: 793 Uploads: 10	Sorry, I have no idea about those numbers but I have noticed that in describing the whole process you used often the words before and after as if you were sure that the discussed variables are times. Is it so, or am I misunderstanding your reasoning?

03-26-13, 09:04 PM	#1571
gap Navy Seal Join Date: Jan 2011 Location: CJ8937 Posts: 8,214 Downloads: 793 Uploads: 10	Totally off topic (well, actually the topic is that I finally catched you online ), can you please look at this issue with the twin M42 gun, when you get time for it? http://www.subsim.com/radioroom/show...postcount=1940 I suspect that the problem could be in some hardcoded gun camera or tooltip assignation, as it only appears when walking close to the gun. Otherwise the gun works perfectly. If you want, I can send you my files making the gun available as armament upgrade.

03-27-13, 06:56 AM	#1574
Vanilla Lieutenant Join Date: Nov 2006 Location: St. Petersburg, Russia Posts: 264 Downloads: 72 Uploads: 0	1/3 power (cube root) is to give lesser speed increase at greater speed orders. That is - less and less efficiency (speed increase) at greater and greater PS applies. Just look at the plot of the cube root. NB: Cube root works well both for positive and negative ordered speeds as compared to even roots (that is why it is not square root - 1/2 power). I will give my full analysis later, I am at it at the moment. My wild guess so far is that it is xmm2 you should tinker with to lower or increase the engine 'efficiency'.