[Question] Sea floor collision damage & room access.

Anachronous · 08-17-11, 05:00 AM

I've only been back playing SH for a couple day, but I have a couple questions for those experienced SH modders.

I noticed while attempting (unsuccessfully) to avoid 8 destroyers and their depth charges, that the sea floor collision is set higher than how it looks visually. Meaning my Sub will hit the bottom while visually I still have considerable clearance. I also noticed that upon hitting the bottom, and no matter how gently I try to do so, the sub will not simply sit there, but will bounce, and which each bounce it will take hull damage.

With this in mind, is it possible to disable the impact damage of the sea floor, or possibly tune it so the sub will only take damage when hitting above a certain speed? It's bad enough being hunted, but hitting the invisible sea bed and constantly taking damage while trying to get flooding under control just makes things frustrating.

Second. I notice that the flooding animation will only display water to a certain depth within the sub. At one point I had a room 50% flooded, but visually it was only up to their ankles. Would it be possible to have the hatches close and block access to those rooms if the flooding is over a certain amount? This would bring a new element of challenge to the game, if one could be locked out of a particular area of the sub while it is flooded.

TheDarkWraith · 08-17-11, 08:52 AM

Quote:

Originally Posted by Anachronous

I've only been back playing SH for a couple day, but I have a couple questions for those experienced SH modders.

I noticed while attempting (unsuccessfully) to avoid 8 destroyers and their depth charges, that the sea floor collision is set higher than how it looks visually. Meaning my Sub will hit the bottom while visually I still have considerable clearance. I also noticed that upon hitting the bottom, and no matter how gently I try to do so, the sub will not simply sit there, but will bounce, and which each bounce it will take hull damage.

With this in mind, is it possible to disable the impact damage of the sea floor, or possibly tune it so the sub will only take damage when hitting above a certain speed? It's bad enough being hunted, but hitting the invisible sea bed and constantly taking damage while trying to get flooding under control just makes things frustrating.

Second. I notice that the flooding animation will only display water to a certain depth within the sub. At one point I had a room 50% flooded, but visually it was only up to their ankles. Would it be possible to have the hatches close and block access to those rooms if the flooding is over a certain amount? This would bring a new element of challenge to the game, if one could be locked out of a particular area of the sub while it is flooded.

The sea floor collision problem is (appears to be) the bone Room_EXT that is placed below the sub. This bone is hitting the floor causing the game to think the sub is on the bottom. I've tried editing the GR2 file to move this bone but it won't move no matter what I try

I haven't found a way to control the hatches other than clicking on them with the mouse.

The reason the flood water only goes to their ankles is because it will not spill over to other compartments if you let it raise any higher. Thus the devs limited it to ankle height.

Anachronous · 08-17-11, 09:23 AM

I appreciate the reply. It's good to know that someone has looked into the issue with collision, even if it is currently bad news on any possible fix.

It was a little disappointing to realise the doors are nothing more than visual. When I first saw them, I was expecting to have to seal off sections, sacrifice men and deal with finding replacements. I miss the crew management of previous SH.

I would assume that if one could close those doors automatically, then it would be done once the flooding reaches a certain percentage, to similar it reaching bottom of the hatch. So while we wouldn't get to see overflowing water, the closed hatch would give the impression that it would do so if opened.

I'll keep dreaming and keep playing.

francho1961 · 08-17-11, 09:44 AM

Regards friends, graces for exposing this important topic for a good simulation, gentleman TDW, it makes me happy to know that always this slope of the friends who need help, graces for his modesty.
Excuse for my English evil, regards.

0rpheus · 08-17-11, 10:06 AM

Quote:

Originally Posted by TheDarkWraith

The sea floor collision problem is (appears to be) the bone Room_EXT that is placed below the sub. This bone is hitting the floor causing the game to think the sub is on the bottom. I've tried editing the GR2 file to move this bone but it won't move no matter what I try

Real shame that as this infuriates me sometimes! Fingers crossed you figure it out one day

Paris_England · 08-17-11, 12:53 PM

Quote:

Originally Posted by TheDarkWraith

The sea floor collision problem is (appears to be) the bone Room_EXT that is placed below the sub. This bone is hitting the floor causing the game to think the sub is on the bottom. I've tried editing the GR2 file to move this bone but it won't move no matter what I try :damn

Hi TDW,

Where are you seeing this bone? Can you see it in Goblin?

I can see Cam01_wake_up_box from QR1 which seems to have something attached way below the sub (it appears as a green triangle in goblin).

Could that also have something to do with the sub floor problem?

Paris_England · 08-17-11, 12:56 PM

Nevermind -- I found it with Granny-Viewer.

TheDarkWraith · 08-17-11, 01:16 PM

Quote:

Originally Posted by Paris_England

Nevermind -- I found it with Granny-Viewer.

You can see it in Goblin Editor also but Granny Viewer is much easier to see. The little triangle dangling down way below the subs doesn't do anything - I moved it and no change. It's this bone I'm referring to that I'm 99% sure is the problem why the sub won't sit on the bottom.

Paris_England · 08-17-11, 01:22 PM

In the hex __ x, y, z value sets for waypoint room_ext (NSS_Uboat7a.waypoints.GR2)

00004e0: 0.00000000 0.00000000 1.4012e-45 0.00069199 1.61885500 0.00000000 0.00000000 0.00000000
0000500: 0.00000000 1.00000000 1.00000000 0.00000000 0.00000000 0.00000000 1.00000000 0.00000000
0000520: 0.00000000 0.00000000 1.00000000 1.00000000 0.00000000 0.00000000 0.00000000 0.00000000
0000540: 1.00000000 0.00000000 0.00000000 0.00000000 0.00000000 1.00000000 0.00000000 -0.0006919
0000560: -1.6188550 0.00000000 1.00000000 11.8530035 0.00000000 0.00000000 0.00000000

Not sure why there are two sets (or rather what they do with regard to the engine -- I have noticed that animations seem to be mirrored in granny viewer so maybe the inverse set has something to do with that).

In Goblin, if I edit the file to the above I do see a shift of the room_ext bone -- not tried it in game so I can't be sure it does anything. I would assume this will move all the exterior waypoints along with it, but if it works it's a start!)

TheDarkWraith · 08-17-11, 01:45 PM

Quote:

Originally Posted by Paris_England

In the hex __ x, y, z value sets for waypoint room_ext (NSS_Uboat7a.waypoints.GR2)

00004e0: 0.00000000 0.00000000 1.4012e-45 0.00069199 1.61885500 0.00000000 0.00000000 0.00000000
0000500: 0.00000000 1.00000000 1.00000000 0.00000000 0.00000000 0.00000000 1.00000000 0.00000000
0000520: 0.00000000 0.00000000 1.00000000 1.00000000 0.00000000 0.00000000 0.00000000 0.00000000
0000540: 1.00000000 0.00000000 0.00000000 0.00000000 0.00000000 1.00000000 0.00000000 -0.0006919
0000560: -1.6188550 0.00000000 1.00000000 11.8530035 0.00000000 0.00000000 0.00000000

Not sure why there are two sets (or rather what they do with regard to the engine -- I have noticed that animations seem to be mirrored in granny viewer so maybe the inverse set has something to do with that).

In Goblin, if I edit the file to the above I do see a shift of the room_ext bone -- not tried it in game so I can't be sure it does anything. I would assume this will move all the exterior waypoints along with it, but if it works it's a start!)

Your first reds are the object's position in model space. Your last reds are the inverse transform (part of it)

I changed the object's position and inverse transform and couldn't get a response from Goblin Editor

Every other one I have changed in a GR2 file reacts except this one for me...I'll try again.

Paris_England · 08-17-11, 01:51 PM

Maybe you did what I did __ edited the VIIA waypoints, loaded up the type B in Goblin and wondered why nothing had moved

TheDarkWraith · 08-17-11, 01:59 PM

Quote:

Originally Posted by Paris_England

Maybe you did what I did __ edited the VIIA waypoints, loaded up the type B in Goblin and wondered why nothing had moved

No, didn't do that. Just tried it again. Edited the 7c GR2 file. Opened it up in goblin and no change in position

Viewed it in Granny Viewer and change is there but Goblin doesn't show position change.

The waypoints file 'binds' to the nodes defined in the sub's GR2 file. Thus editing the waypoints GR2 file is not going to move the bone in the subs GR2 file.

Paris_England · 08-17-11, 02:12 PM

Here's what I see in goblin (you can just make out the axes of the bone above the main origin). Before the edit the axes were below the origin...

Maybe I'm editing the wrong thing, but it sure does look like the bugger you're talking about.

TheDarkWraith · 08-17-11, 02:18 PM

Quote:

Originally Posted by Paris_England

Here's what I see in goblin (you can just make out the axes of the bone above the main origin). Before the edit the axes were below the origin...

Maybe I'm editing the wrong thing, but it sure does look like the bugger you're talking about.

you're editing the waypoints GR2 file. Edit the subs GR2 file and see what happens. I can make the waypoint one change no problem. It's the actual sub's GR2 file that I can't for this node.

TheDarkWraith · 08-17-11, 02:30 PM

Finally got the node to change position in Goblin. I removed the 7C folder from the \data\Submarine folder of the game. Made a quick mod that had only the edited 7c sub GR2 file in it. Enabled said mod. Opened up Goblin and loaded 7c sub GR2 file. Node changed position. This tells me that everything that is bound to this node also has to have it's position changed to reflect the change made to the sub's GR2 file for this node

How's that for confusing?

It's either that or some file in that 7c folder is modifying the node's position during runtime (or viewing in Goblin)

EDIT:

added the GR2 files defined by the MASM file (and the MASM file itself) to the said mod's 7c folder. Enabled said mod. Viewed in Goblin and no change to node's position. So one (or all) of the files defined in the MASM file is changing the node's position.....More detective work required

08-17-11, 05:00 AM	#1
Anachronous Medic Join Date: Nov 2002 Location: Tasmania Posts: 167 Downloads: 22 Uploads: 0	[Question] Sea floor collision damage & room access. I've only been back playing SH for a couple day, but I have a couple questions for those experienced SH modders. I noticed while attempting (unsuccessfully) to avoid 8 destroyers and their depth charges, that the sea floor collision is set higher than how it looks visually. Meaning my Sub will hit the bottom while visually I still have considerable clearance. I also noticed that upon hitting the bottom, and no matter how gently I try to do so, the sub will not simply sit there, but will bounce, and which each bounce it will take hull damage. With this in mind, is it possible to disable the impact damage of the sea floor, or possibly tune it so the sub will only take damage when hitting above a certain speed? It's bad enough being hunted, but hitting the invisible sea bed and constantly taking damage while trying to get flooding under control just makes things frustrating. Second. I notice that the flooding animation will only display water to a certain depth within the sub. At one point I had a room 50% flooded, but visually it was only up to their ankles. Would it be possible to have the hatches close and block access to those rooms if the flooding is over a certain amount? This would bring a new element of challenge to the game, if one could be locked out of a particular area of the sub while it is flooded. __________________ Use of undefined constants causes assumptions!

08-17-11, 09:23 AM	#3
Anachronous Medic Join Date: Nov 2002 Location: Tasmania Posts: 167 Downloads: 22 Uploads: 0	I appreciate the reply. It's good to know that someone has looked into the issue with collision, even if it is currently bad news on any possible fix. It was a little disappointing to realise the doors are nothing more than visual. When I first saw them, I was expecting to have to seal off sections, sacrifice men and deal with finding replacements. I miss the crew management of previous SH. I would assume that if one could close those doors automatically, then it would be done once the flooding reaches a certain percentage, to similar it reaching bottom of the hatch. So while we wouldn't get to see overflowing water, the closed hatch would give the impression that it would do so if opened. I'll keep dreaming and keep playing. __________________ Use of undefined constants causes assumptions!

08-17-11, 09:44 AM	#4
francho1961 Officer Join Date: Dec 2009 Location: Alicante - SPAIN Posts: 249 Downloads: 969 Uploads: 0	hi, comandants. Regards friends, graces for exposing this important topic for a good simulation, gentleman TDW, it makes me happy to know that always this slope of the friends who need help, graces for his modesty. Excuse for my English evil, regards.

08-17-11, 12:56 PM	#7
Paris_England Soundman Join Date: Aug 2010 Posts: 144 Downloads: 79 Uploads: 0	Nevermind -- I found it with Granny-Viewer.

08-17-11, 01:22 PM	#9
Paris_England Soundman Join Date: Aug 2010 Posts: 144 Downloads: 79 Uploads: 0	In the hex __ x, y, z value sets for waypoint room_ext (NSS_Uboat7a.waypoints.GR2) 00004e0: 0.00000000 0.00000000 1.4012e-45 0.00069199 1.61885500 0.00000000 0.00000000 0.00000000 0000500: 0.00000000 1.00000000 1.00000000 0.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0000520: 0.00000000 0.00000000 1.00000000 1.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0000540: 1.00000000 0.00000000 0.00000000 0.00000000 0.00000000 1.00000000 0.00000000 -0.0006919 0000560: -1.6188550 0.00000000 1.00000000 11.8530035 0.00000000 0.00000000 0.00000000 Not sure why there are two sets (or rather what they do with regard to the engine -- I have noticed that animations seem to be mirrored in granny viewer so maybe the inverse set has something to do with that). In Goblin, if I edit the file to the above I do see a shift of the room_ext bone -- not tried it in game so I can't be sure it does anything. I would assume this will move all the exterior waypoints along with it, but if it works it's a start!)

08-17-11, 01:51 PM	#11
Paris_England Soundman Join Date: Aug 2010 Posts: 144 Downloads: 79 Uploads: 0	Maybe you did what I did __ edited the VIIA waypoints, loaded up the type B in Goblin and wondered why nothing had moved

08-17-11, 02:12 PM	#13
Paris_England Soundman Join Date: Aug 2010 Posts: 144 Downloads: 79 Uploads: 0	Here's what I see in goblin (you can just make out the axes of the bone above the main origin). Before the edit the axes were below the origin... Maybe I'm editing the wrong thing, but it sure does look like the bugger you're talking about.

08-17-11, 02:30 PM	#15
TheDarkWraith Black Magic Join Date: Jun 2007 Posts: 11,962 Downloads: 147 Uploads: 5	Finally got the node to change position in Goblin. I removed the 7C folder from the \data\Submarine folder of the game. Made a quick mod that had only the edited 7c sub GR2 file in it. Enabled said mod. Opened up Goblin and loaded 7c sub GR2 file. Node changed position. This tells me that everything that is bound to this node also has to have it's position changed to reflect the change made to the sub's GR2 file for this node How's that for confusing? It's either that or some file in that 7c folder is modifying the node's position during runtime (or viewing in Goblin) EDIT: added the GR2 files defined by the MASM file (and the MASM file itself) to the said mod's 7c folder. Enabled said mod. Viewed in Goblin and no change to node's position. So one (or all) of the files defined in the MASM file is changing the node's position.....More detective work required