maybe this whole topic is starting to get very interesting....

:hmmm:

smells like endless possibilities...does it?

Of Course...Maybe there is a need to have some support using the tools :DL

yap, i think so. this is why i started this thread ;)

So, when will PT, DD, CL and CV shot their torpedoes to surfaced uboats?
:03:

Well I had a patch all made up, and decided to test the Mod after applying the Patch.

Hmmm, the stadimeter worked ok, but going to the other dials it looks like there's some unwanted side effects.
The Range Dial no longer turns and the reset to zero bug is more obvious now.

I've done some digging and noticed that the Memory address that I was using for the fix is also being used by not only Range - But AOB, Target Speed and Bearing.

So that explains the Reset to Zero Bug - All these dials are sharing the same Address's to store the value before updating the final value for the relevant dial.

So for example If i set my range its stored in this address, now if I change to AOB it resets to zero (Because the AOB is currently set at 0 degrees so that value is moved to the address) Overwriting the one for range that was stored there.

This was very sloppy programming on behalf of the Devs - Why not give ever dial its own address for storing the temp values - like every other game out there. :nope:
Its not like a couple of dials each using a float space in memory is going to amount to much memory maybe 20Bits (160Bytes) in total. Especially when some of the dials have multiple copies of the same value stored in different addresses - where only one is needed - Bad management of the memory.

Looks like this is going to take more than changing the offesets due to the shared address Issue. :wah:

SOUND!

Sound is what needs to be fixed.

We have only ONE stinking internal ambient sound for the submarine. Doesn't matter if you're surfaced, submerged, silent running or what not, the same ambient sound is played.

Now, as a sound editor myself, I could do us WONDERS if we could patch the exe in order to include a function calling different ambient sounds for different situations of the uboat.

I don't know squat about RE, my skills lies elsewhere. But teamwork wins right?

:woot:Fantastic find reaper :woot:

Hope you can fix it:yeah:

yes, this find prooves the devs where under an extreme pressure of time and the programming is not the state of art over there in romania. what a shame...to present a full price game at this unfinished and unprofessionally coded state to us...

:nope:

what would we do without people like you, that got the skills to change all these crappy and unfinished delivered things...

i have a lot of respect for people like you and tdw.

:yep:

Cheers Mate, I wish I had the skills. Only just getting the Basic on how code works. Never did Assembly or reverse engineering before.
Only going on the few youtube tutorials I've found on pointers and addresses.
So not even sure I can figure out how to circumvent the current code.
Most likely going to take some new assembly code injected into the exe (Via patch) to reroute the current dials to individual memory locations for temp before routing them to there final value locations :hmmm:.

thougt of the same thing. address a whole new area of memory for that, if it is possible. but this was only a thought as to the note of tdw, that we can inject things and change calls in the exe file. that sound to me, as if we might be able to change nearly every file/shader/library the exe uses or calls.

and in the end: i am a noobnoob. so, just a thought, mate.

anyway, you are doing great work. keep it on. i wish i had the time to learn this stuff. i would definitely change a lot of elemental things!

What this sounds like is the programmer assigned each 'variable' to a temp variable so as to preserve the original variable. When the C++ code was compiled (and compiler optimized it) the compiler usually places temp variables on the stack (instead of the heap). Being that it was optimized the compiler probably decided to use the same address (stack address) for each temp variable (to save memory). This is why you are 'seeing' each variable using the same address. This is very common to see and is one reason why RE is very complicated to 'follow and decipher'. If you want to validate my theory then you'll probably notice that the address used for each 'variable' uses offset addressing to 'find' it's contents (ESI+x where x is the offset amount - and ESI could be any of the general CPU registers [EBX,ECX,ESI,EDI,etc.]). In this example ESI would be an address located on the stack (you can find where the stack is located via Olly Debug - EVERY application has at least one stack but usually they have more than this)

LOL, thats exactly whats happening - I had come to the same conclusion.
I went back to Cheat engine this morning and fired up SH3 (As its quicker to load and easier to trace - but basically the same).

I was able to trace the pointer's all back to the same Base Address - and each of the dials is then written to by means of an offset.

Thanks TDW for confirming this :up: It makes much more sense to me now - and not an issue of bad programming as I first thought. Sorry Devs :up:.
Just a Noob jumping to the wrong conclussions :88).

Good thing we have professionals like you who can judge programming skills from incomplete, misinterpreted due to lack of knowledge and probably incorrect statements read on forums.

yes... you are lucky guys:)

EDIT: you pm box is full

uhhh. feels like i tread on someones toes here, did i? please address your personal anger to the ones, who are responsable!

even if the code may not be unprofessionally coded, the game is unfinished and so the code is and THIS is unprofessional. thats a fact no one has to study it deeply for. and as you dive deeper into modding, you will find (even like in sh3 and sh4!) unfinished code parts. functions, that have been planned to be added, but never where.

so brother, step off my foot and judge the greasy tie guys from ubi for this piece of crappy software! and i think you will find 1 of 10 here, who was satisfied with this release. blame the ones who caused this...

dude.

Go thru Pinteas posts and see all the things he has helped with .

So please keep bashing the suits with your complaints.
I was speaking in defense of the programmers and your "unprofessional/bad programming" claims. You have insufficient information/knowledge to be judging "programming skills in Romania".

Knowledge/information on their ability and willingness to work well - it's SH 5 and the "curve" code.

Pintea has every right to take your criticism personally, if you get my meaning.

Stop side-tracking the topic.

butthurt about someone making claims on bad programming for the game? Well, considering that the stadimeter bug does exist and not just "insufficient information/knowledge"... I would suggest you helping reaper to fix it, instead of complaining that he has no idea wtf he is doing... Especially after he admitted that he was wrong in his judgement.

dixi