Excellent news!

This just gets better and better:D

ssshhhh....be quiet, mates. Genius at work! :yep:

amazing work:rock: . but i still dont understand this sentence. does that mean modders can change 97-98% of all the changeable options a sdk could change? does that mean everything of non-hardcoded content is changeable with your tool? i am not a modder, i only follow the technique discussions here with high interest...


greetz, Jaeger

Hi Jaeger, a SDK could contain more tools and even source code, so it depends a little.

But to give you an idea, the DAT-file format is used by roughly 5000 stock files in both SH3/SH4/UBM combined and makes up the bulk of the game (textures, audio and non-binary data like cfg/txt not counting). In essence, there's not much binary data/files left to support by S3D or other tools. There are a couple of file extensions left that are not supported by S3D right now but there's some other tools that do (ie. terrain extractor) so there's no real point for me unless I am REALLY bored.

So yea, the percentage indicates most game data can now be worked with by the modders.

What is not supported (and never will be) is actual (hard)coded game behavior, which makes up the actual software part (.exe, .dll, .act). This would require source code, per SDK. This will not likely happen however.

thanks for your replay, now i understand better:up:

Hi skwasjer,

when I load SH3 scene.dat in S3D v0.9 I wondered if this file is fully supported by S3D.
I noticed in e.g. MiniTweaker are much more items available... :hmm:

Cheers,
SquareSteelBar

Yes, scene.dat is fully supported and has been for a very long time. Not every value in minitweaker is named the same in S3D though, because I use the actual game description. If you specify which values you see in MT that you can't find in S3D, me or others can point you to the right place.

I was looking for WindHeadingChangeSpeed and WindSpeedChangeSpeed

Thanks in advance,
SquareSteelBar :up:

Picture's worth a 1000 words
 

Thanks, DT :rock:

Very weird. I use a modded scene.dat [it works!]; it seems that it has been corrupted:

http://img141.imageshack.us/img141/8827/scenedatpo3.jpg

I'm going to look for the error...

THX again. ;)

Any time. That is strange. Of course, it might make a difference that I was looking at an SH4 scene.dat (haven't had SH3 installed in ages). Perhaps someone with SH3 could try opening the scene.dat to see if they have the same problem?

I don't know how much difference there is between the scene.dat in the two games, but there doesn't seem to be much difference in the screenies (other than the obvious problem one).

The stock SH3 scene.dat was opened correctly in S3D. The error was in the modded one; finally I found it -> two faulty values...

Cheers,
SquareSteelBar :up:

Glad you found it, and yes, in case of a corruption, S3D just reads the data as a byte array where possible so you can at least work on the other parts in the file.

Just some status update, nothing big, and no release announcement...

I've got a bit confusing PM from Anvart that NightColor on Omni nodes is not actually the night color but something else. What is not really clear at this point but I hope Anvart can clarify it, and I will investigate it further. May explain some oddities people may have been experiencing with this field.

[edit] OK, Anvart just told me he doesn't know for sure and that it has to be tested further, so I will have to do some tests on this field.

Next, I have found out some more unknown data on material chunks, specifically rendering flags like 'Disable Z-buffer write' and 'Cull none'. These flags are important for single plane meshes (like railings) and (semi-)transparent meshes (like glass). If you are cloning incorrect materials, ingame the models may not be rendered correctly (for instance, railings may suddenly disappear from a certain angle due to culling, or objects behind glass are not rendered at all because they are clipped by the z-buffer). These new flags allow you to modify this behavior as well.