Hi TDW,
I've discovered one more SHcolision.act CTD scenario with probable cause and even rough solution. I hope that you could shade more light on this issue...

So, the game will CTD (fault module SHcolision.act)when AI unit is engaged with deck gun and then declared dead by the game, but without catastrophic explosion.
Few minutes later , when the same unit "burn off" and catastrophic explosion occurs , at the same moment the game will CTD, not every time but most of the time...

Ineresting thing is that, if I remove manually TDW_FXU_Debris_Materials.DAT from library folder, I wont be able to reproduce this CTD anymore. But of course, floating debris wont be rendered in the game.

Looking forward for some info on this issue...

Since you are able to reproduce this I assume then if you really want to figure out why you'll need to run the game inside of OllyDebug 2.01.

It's really easy to do and then you'll be able to tell me exactly where the problem is in SHCollisions.act.

You can get OllyDebug v2.01 from here: http://www.ollydbg.de/version2.html

Right after September 27, 2013 - version 2.01 click on OllyDbg to download v2.01.

To use:

Start SH5. Go into career game or single mission. Once in the career game or single mission start OllyDbg by double clicking it's icon on your desktop. Now select File-->Attach and select SH5. This will 'attach' OllyDebug to SH5. Once attached then any errors, exceptions, etc. will have OllyDebug 'break' to the actual offending assembly instruction. VERY HELPFUL in figuring out why CTDs happen!

Now if you right click on the far left side where all the address numbers are you change how the addressing is shown. First, scroll the window to the very top. Now double click the far left side to get into relative addressing. The first entry will be 0. Now click any assembly instruction to highlight it. Right click and select goto origin.

Now all I need to know is the module (SHCollisions.act, SHSim.act) that is currently active in the window and what the relative address is.

Actually the best thing you can do is take a full screenshot when an error/exception occurs and OllyDebug breaks to the offending assembly instruction and send it to me (following what I said above first for relative addressing - without the relative address of the offending instruction I have nothing to go by because the OS loader will load modules at different addresses everytime you run the game).

Very nice! I'll take a look at this and post findings...:up:

Once you become semi-familiar with OllyDebug you'll see it's a VERY simple yet POWERFUL disassembler/debugger. It's the only thing I use to develop patches for my Generic Patcher for SH5 or any other app :up:

Once 'attached' to a process you'd never know anything different as the process continues on normally like nothing ever happened (most of the time - unless the process has some form of copy protection that's looking for something like this).

This "attaching" process could last for some time , right?

It will stay attached until you either detach or close OllyDebug down (if you close OllyDebug down the attached process will stop also)

Well, I've got good news and the bad news...
Bad news are I couldn't replicate CTD and the good news are - I couldn't replicate CTD...:D

Continuing testing...

Some how I'm having a feeling that casualties are involved (poor men flying around when shell hits) and today I couldn't spawn any casualties no matter how hard I struck the ships...:hmmm: We'll see...

Just to make sure that I understood you correctly TDW I'll show you OllyDbg report from other 100% reliable CTD of mine...:) This one can't escape...

It's scenario where random unit appearance will crash the game if game isn't fully restarted after the start of certain campaigns... Example:
You star campaign in Kiel, enter bunker, exit to main manu, then museum, after few units- CTD or...
Enter the museum and pay extensive visit, then start new campaign, and the game will CTD

We talked about this issue on this page...http://www.subsim.com/radioroom/show...89818&page=329

http://s6.postimg.org/agcvbj6ct/Capture.jpg

Does this picture tell you anything TDW?

Is that where OllyDebug 'broke' into? It highlighted that call statement? Did it say anything like null reference or ??

Actually what you are seeing is the beginning call into SH5. If you look at the EDX register it holds the address of where the module start point is for SH5. Something called EDX which then OllyDebug breaks at the module entry point (if that option is set which under default settings it is). Let OllyDebug 'continue' by pressing the Play symbol (fourth button from the upper left).

I'll warn you now that 'watching' SH5 startup will lead into many exceptions thrown. You'll have to press Shift+F9 to let the app (SH5) handle those exceptions. You'll end up pressing this key combination something like 50+ times :dead: Yes, SH5 is coded awful :-?

Interestingly with the moon and the moonlight mod
http://www.subsim.com/radioroom//dow...o=file&id=4350
I get a beam of light from the lighthouse .
http://i60.tinypic.com/ea30xf.jpg

Cinematic Firelight
 

It would be neat if burning ships could be fitted with an appropriate light source , so that the fire would light up objects and throw shadows .

Ive looked for light like this and if its there its very faint and perhaps should be cranked up , But im pretty sure there is no light produced at all . Ive done laps around burning ships looking for it ..

Just a thought i had to share ..

The fires (and most effects) are just Sprites which is why they don't give off any light. They would need to be actual 3D objects in order to cast shadows.

Thank you .
Its just an idea and i know if it could be done it probably already would have ,,

It would be a neat effect tho , To light up the night with the flames .

You couldn't include dear TheDarkWraith in your FX Update for SH5 by TheDarkWraith fashions of an exhaust of diesels of the submarine?