is there a way to add a name to them so i dont have to keep going back to the dat? i know i can add a name but is it "safe" to change the label name? will it still work in the game with a different name?

i would rather spend time attatching names to them all so later it make life easier.

You can attach a label chunk to a controller, the game won't mind generally speaking (unverified). Just remember that using a reserved name might cause issues (again unverified), and as chunks get reused often it's also more work to manage. That said, I still recommend you remove them from 'published' work because it's best to stay as close to original stock chunk-layout as possible, because it will only be more confusing in the long run (to others anyway).

I just use search function, to me it's faster than adding labels to all chunks.

Another tip is to reorder chunks in a zon or sim-file to match the DAT. Sometimes in stock this isn't the case.

i want to be sure we are talking about the same thing so let me explain my plan.

in the shells.zon every node has the same name, they are all labeled "AmmoDamageInfo" and they only have different ID numbers to tell them appart.

what i wanted to do was take the name of the coresponding node in the dat and use it to be the new label name.

so in the zon file "2:node - AmmoDamageInfo" has the parent ID 0x765548d9c98196cc

and in the dat file "node 203: 30mm_HE_shell" has its parent ID 0x765548d9c98196cc

so if they share the same parent ID and that means zon "2:node" is for the "30mm HE Shell"

so what i wanted to do was take the zone files "2:node" and give it the exact name i copied fron the dat files "node 203:" and name it like this:

2:node - 30mm_HE_shell

and when i do that the 3:node (child node) automatically becomes

3: !30mm_HE_shell ! - AmmoDamageInfo


i thought it was best if i was going to name things in the zon, it would be best to name them exactly the same way as they were named in the dat file so the game would recognize it. i dont know if my thinking that is correct or not.

hopefully that makes clear my question.


so is this something ok to do or could it cause problems.

Do not change the name of the controller... Perhaps it works, but I rather think it won't and suggest doing as indicated.

ok, i will not change anything. :salute:

i'll just write it all down somewhere to use as a reference when i need it.

:rotfl:
In HexEditor you can see your work in details ...

Sorry ... of topic ...

Tought I did that about a year ago:

[TEC] Shells.dat + Shells.zon Node Numbers in 1.5

Now in download section too.

Hey skwasjer,
I want to change some of the in-game fonts but S3D crashes whenever I open an off file. I've tried both editing existing .off files and creating a new one, but whatever I try it just don't work :damn:
I've tried it on two different PC's, one XP and one Vista, but all I get is the following message (in Dutch but that shouldn't be a problem to you;)):
I'm using S3D v0.9.4
I hope you can fix this or tell me how to successfully edit those files if it's not s3d related

http://img150.imageshack.us/img150/3511/55inchbrass.jpg


S3D does not look in the texture directory but the .dat's directory for the texture !!! :nope:

I had to create a new separate dir with the gun.dat and the occlu and texture to test the .dat...

keltos

weird... I always put custom textures in the textures\tnormal\tex folder. And I've never had any problem with textures not showing up.:hmmm:
Were you working in your normal game folder (...\Silent Hunter 4 Wolves of the Pacific\Data\....) or a different directory? Cause probably S3D can't find the textures folder if the texture folders are placed in another directory (e.g. ...\AnotherDirectory\Data\textures\...).

There are different types of material. If you tell it to look in the same directory for the material, then it will. There are some system labels that it uses and replaces to get the directory, that's what the cfg_TXR and other such lables mean in the mateiral property. You can also have internal textures, that have the graphics contained within the .dat file and of course external textures. It will only look where you tell it :-).

Hi DarkFish, it seems like I've mistakenly left out one DLL from the installation program which is required for editting the OFF files. Thank you for the information, I will fix this asap. I can not give you a quick fix right now, because I don't have a copy of the DLL anymore that works with 0.9.4 as changes have incremented over the past months resulting in an incompatibility. Stay tuned for a full fix in the next weeks.

It does, but the search routines are a bit different from the game because S3D also has to take into account your mod directory. However, the local directory where the .DAT resides takes precedence over the global texture folder. Not only that, S3D takes this into account:

* Search local folder in your mod: <MODS>\<Your mod>\Data\<Folder with Dat-file>
* Search local folder when MOD is installed in game: Data\<Folder with Dat-file from your mod>
* Search global texture folder in your mod: <MODS>\<Your Mod>\Data\Textures\TNormal\tex
* Search global texture folder: Data\Textures\TNormal\tex

Additionally, S3D obviously also looks for internal textures.

As you can see, it's a little bit more complex than it appears ;)

Conflicts can happen when the material is not set up correctly, like Nisgeis indicates, or when textures with the same name are used (and worse, stored in more than one of the locations mentioned above), resulting in incorrect representation in the 3D viewer. There's more odd scenario's possible when mods are intermixed, enabled over eachother, etc. where you expect a texture to show up, but S3D can't find it because it's outside its search path, or if S3D finds another (old one) first.

A good example of unexpected texture loaded is the prop_black.tga which comes with each airplane. The game has that file in the global texture folder but also each plane has it as internal texture. Replacing the internal texture will not yield expected result as the global texture is still used (it takes precendence over internal textures, although it makes more sense if it didn't). Only after removing the global texture will you see the new internal one.

I tried to best match the game load behavior but since mods during design time generally reside in their own \MODS location, I had to deviate from the game it's method of loading and resolving textures. That and the fact that it's not documented by Ubisoft how textures are resolved, all I could do was guess/test and try to come as close as possible.

okay, thnx. I already figured it was something like that (what else can a missing assembly be?) but I had absolutely no idea what file was missing from where.
.off eding isn't exactly the most used function of S3D so I guess it's not hard to forget adding the .dll
BTW thanks for creating S3D, I've used it ever since v0.7 and it just keeps getting better and better! :yeah: can't wait for v1 to be released!

Please could someone give me some tips on how to get a texture be applied on a 3D object.

ouside S3D I have an object with texture

On S3D when I import the object plus add its texture on the node it shows the object with the texture. But when I launch SH4 the object is black.

I don't know what I'm doing wrong...

S3D doesn't complain on object import and it shows the object with correct texture... so why SH4 doesn't show the correct texture? :damn:

Help!!! :06:

Thanks

There are a number of things that could cause this. 1st, are you sure the uv2-map is textured right? just enable ambient occlusion map in S3D model preview to check this. maybe it's just the O01 texture that's causing the blackness.
2nd: SH4 doesn't seem to like it if the index of the texture is higher than the object's index. Look if the texture is placed above the object in the S3D tree (as it should) or below.
I've had this problem a number of times and usually it's one of these 2 problems that causes black textures.

Correct :up:

here are the pictures

http://www.ribeiros.co.uk/img/s3d.jpg

http://www.ribeiros.co.uk/img/s3dobj.jpg

Now the above 3D object appears black on SH4... what I'm missing here? Thanks

Your material has the same texture linked for the lightmap (ambient occlusion map) which is wrong. The lightmap is always a different texture, which contains lighting/shading info. Secondly, do you even have the texture coordinates for the lightmap (uv2) on the model? If not, then you should remove the 'yellow bulb' chunk, so the game can render the model with only a diffuse pass. If you do, then the 'yellow bulb' chunk should point to a proper ambient occlusion texture, for the ambient occlusion pass to work. If not, well, black... ;)

Note: S3D behaves a little differently in some scenario's.

Import problem

I have build a simple box in 3ds Max 9 and assigned to it a Multi/Sub material with 3 map ID's (red.tga, blue.tga, green.tga). The box is devided in 3 parts and the faces in each part has a material ID (assigned from top -> 1, 2, 3) and a uvw mapping in map channel 1, so in Max it looks correct.

http://foto.arcor-online.net/palb/al...3861386233.jpg

I export the model to the obj format and open it in a different app which can read obj files and it also looks ok.
http://foto.arcor-online.net/palb/al...3238346233.jpg

Now I import the obj model into a DAT file. The DAT contains the 3 textures (red.tga, blue.tga, green.tga) as separate materials and these materials are assigned to the box node but the preview is not correct and also not ingame (SHIII).

http://foto.arcor-online.net/palb/al...3462616635.jpg

If I export this model again and import it into 3ds Max 9, the material ID's are re-assigned as in S3D and the uvw mapping is corrupted.

Requires each material its own mapping channel or does S3D not support the import of Multi/Sub material in one mapping channel in a correct manner?

Here is the MTL file of the box exported by 3ds Max 9