I've got a new release ready that fixes some of the bugs found earlier: v1.5.1. See first page for link. Uninstall v0.5 first, because this release replaces it.

PS: does anyone happen to have the v0.2 download? Unfortunately I have deleted it from my server by accident and apperently I haven't got a backup on my pc. I want to put this download up again as well, for people that want to run both versions side-by-side.

http://files.filefront.com/S3D+03msi.../fileinfo.html

Thanks lurker_hlb3. I'll rehost the file. Have you tried if the new release I posted this morning still gives you the uxtheme bug? I think it should be fixed...

Doh, I sa A file. Hang, it's not stock. brb

tater

Wierd, I opened the one I was working on last night... and it opened this morning.

Heh... And you haven't updated yet?

Hadn't updated. The only other ones were my DC mod, and an AI torpedo WIP (doesn't work). Pretty sure it was the AI torpedo one, too. opened.

works fine, long time with v0.51

Found a bug when you undo a change of a value in property chunk, I will hold the fix for a day just in case more issues are found

Many thanks skwasjer,

:sunny::sunny::sunny: Merry Christmas to you and your family :sunny::sunny::sunny:

:sunny::sunny::sunny: Merry Christmas to all :sunny::sunny::sunny:

no,no,no,no... You'll get a "merry christmas" when and only WHEN import 3D is actually released... :nope:

Nahhh, just kidding ;)
Very good work from what i've seen so far!!! :up:
You really made an outstanding helping tool for the modding community! many many thanks!

Keep up the good work!! and thanks for the credit by the way ;)
I'm going back to test that frustrating (for good reasons :smug:) export model function eh eh

There are some limitations with the model exporter, but at least all map channels are exported :up: One thing that I think is not right is that the model is broken apart when multiple materials are applied. You will get a mesh for each material. Once I manage to support exports of parent/child (nested) models, I am worried you get too many subobjects...

I have written a doc on the issues and how to correct them, but it's only roughly 50% complete. Any feedback from experienced modellers is appreciated.

Let me know if you have problems with it with the software you use or have screwed up exports. The export code must be as good as can be before import is even considered, so the more you guys test the faster I can work on a solid import function.

I have a question / problem for you
 

In the older vs of S3D you can adjust the values of the Sky colors in the ENV folder

for water reflection.

Data/Env

Skycolors_Arct.dat

Skycolors_Med.dat

Skycolors_Atl.dat

But in the new vs there is only a True or false setting for them no number adjustment like in the old one.

Also in the scene file adjustments.

Data/Scene.dat

With the mini tweeker you can adjust the Horizonal setting for the sub view bubble.

But with the new S3D ap it is saying this is fixed and none adjustable.

With the new game capabilities this does need to be slightly adjusted so why dosn;t the new S3D ap allow this?

The same problem with other water reflection adjustments exsist in other files.

A lot of them that say in this order:

ClipHeight
Reflection
Refraction
Frustrum Test
MinvisDim
MaxVisDim

The 3 I highlighted in yellow no longer have a numericle value to work with.
The last one I do believe should be a True or false setting and should work okay IE FrustrumTest.

But Reflection and Refraction needs to have an adjustable level not just a true or false setting which I have used in the old aplication for my work.

The old aplication has the ability to change the values with the add on's you have given us in the past.

BTW another issue. If a file has been changed by the mini tweeker first like the scene file then your aplication will not open it. But if you take a fresh untouched scene file it will open and adjusted it.

Have seen this with many files so far. It is like your aplication will not read other aplication changes only stock original work from the game.

Is there a property definitions you can add lines to like the last aplication so the new lines we added to the old app to give us more adjustments can be added to the new app? Right now without them you have to use both apps to get some of the same results.

When I was creating all the controller definitions I had to assume which type each value was. This case the value is 1 byte in length, and I made the definition a bool (true/false). If this is wrong, it's easy to correct. You can do this yourself, but I'll update the definition and upload a new version, as I have a few other fixes in place.

What is the horizontal setting for the sub view bubble? Where can I find it?

The new version also has this ability, but it works differently. For now, I'll change the types of the Reflection/Refraction and provide an update.

I have to look into this. Would be great if you could send me some mini-tweaked files, so I can see what's wrong.

Thanks for the feedback :up:

That is wrong, you can not assume that the developers only save the values 0=false or 1=true in that byte because a byte can represent a value from 0-255. In this case Sky colors are RGB colors with values 0-255 for each color component.

Okay in the original game files
 

The original starting values for all of the Reflection and Refractions are set at 1
But I have gone as high as 3 in them so I believe they are capable of going higher but how much I do not wish to guess. Anything above 5 seems to be way too much in an effect. But if you make them absolute to start with a modified file will not open and you will have to start from scratch like the problem I came into with the scene file trying to modify one I had worked on in the past. It will not open it.

And seeing the Frustrumtest dosn't seem to accept anything but a 1 or 0 it is probably true or false yes or no type of deal.

In the scene file if you open up node #50 to #51 and click on the environment in the setings area it tells you it is the Camera Bubble Sphere. Original base value starts at 1000. I know you can go up to 10,000 although that dosn't work well in game. So there are almost no limits to it's setable ability for use.

Do you want already tweeked files or mini tweeker files themselves?!

But as it stands at the moment using the S3D tool for adjusting the Scene.dat file just isn't feasable as it changes things in the file once you save the changes in a way where too many effects are lost that I am trying to work with.

Didn't mean to tear up the new work or ruin your Christmas with this info just wanted to help you out in making it better.

I will start going from file to file for you little by little
 

In the game Directory and find any problems from my old work to new and see what is missing and needs to be fixed.

But I think the old set up worked a little better and had less if not no issues opening a file because it did not believe in absolutes and could open a file that had changes done to it already.

That seems to be the problem with the new app. It wants un moded files to start with or files only adjusted with S3D in the past. Where as the old app could open a file changed with the mini tweeker first lets say color changes first with mini tweeker then value changes with S3D after words. But the new app seems to refuse to open a file that is not stock or was not changed with the old vs of S3D.

So for those of you using or wanting to use S3D for your older mods that used the Mini tweeker to change settings it means having to start your work from scratch with an un moded file.

Also it would be nice if you could double check how the new S3D reads
 

The interior files for the subs. I see settings now for true and false in making gauges adjustable inside of the subs using the mouse. Is this actualy correct or an improper read of the interior files?

If it is correst then that means you can easily set all interior guages in the subs to operate while on an interior camera. I think if it had been that simple we would have had interactive guages mod for the game a very long time ago.

Just got back from a couple of days of xmas holidays...

The values Leo talks about are not RGB colors. Now, you are assuming something wrong... Do I have to mention I know the difference between a byte and a bool? Leo is mentioning values of the WaterReflection controller. I probably shouldn't have said it the way I did. In most cases I didn't assume anything, because the devs left traces of what the types are in the dll's and I can verify values amongst different files to come up with the correct type. In this case I was 'convinced' they were values with only 1/0. The places where I really had to assume types were only few, and I used the safest type possible if I wasn't sure. I was wrong in this case as Leo pointed out to me. Sorry for explaining incorrectly :doh:

I'm sorry if there are incorrect definitions, but I can make mistakes. I've worked through 130+ controllers, and this took me many hours. I just can't test every single value and/or know what the outcome of changing it is. In this case it was my understanding that these values ment 'yes - use/apply reflection' or 'no - don't', same for refraction, and for frustrumtest. It is up to the community/users to find the mistakes and tell me about it. In this case you find some. Those types are fixed in next release.

The Environment controller is a controller without configurable data. It has always been so afaik. So I really don't know what you specifically mean. Probably you are talking about a value that you tweak with minitweaker that sits somewhere else in the file...?

I want both files if that's possible. I can then check what you mean.

What effects are lost?

My christmas isn't ruined. I appreciate your input, you know damn well ;) I also want to make it better, and once the first couple of weeks have passed, and the issues are ironed out you will enjoy the new release like you did the previous.

Just send me the files asap. At this point I can't do anything to check for the problems you have.

Are you referring to CmdOnDrag and RelativeDrag? To my understanding, they are correct. CmdOnDrag afaik means that the command is a drag command, and the RelativeDrag is also related to mouse behavior of dial, and is a yes/no flag. As to what it does, I am not 100% sure, but I think the dial can probably rotate and the values should then be relatively calculated based on where the mouse-drag intially started in the dial. Well, something along that line anyway. I'm sure someone knows.
I've rechecked data of some sim-files (even some SH3/GWX data) and the only values used are 0/1. Only few dials use RelativeDrag.

I do think it is that simple though, just no1 hasn't touched it for SH4. But in SH3 many modders have made changes to (interior) dials or made new dials. What I don't know if the engine of SH4 still 'supports' it, but I don't see why. I just think the devs took interactive dials out, like they did the radioroom, because they didn't have enough time/money. That, or there are other problems...



About v0.5

The new S3D parser is not using absolutes as you may think, it uses controller definitions much in the same way the previous release did, just in a different form. (open up the \Controller folder in S3D install folder and see for yourself) Version v0.2 is actually worse at reading files and more potentially dangerous. You don't realise this, but I know this! In fact, I don't feel comfortable at all at S3D alpha being used for public mods (which is why I labeled it as 'alpha'). If it does work, great, but I don't hold my hand in a fire for it. In fact, v0.2 based mods may break in v0.5 just for that reason... :roll:
You must not forget, I've had to do alot of troubleshooting the first 2 months after that release, because it made many incorrect assumptions when autodetecting, and it still does today! Mods you made may be saved incorrectly which is why v0.5 may fail to read them. The game way of reading the files is obviously different, and apparently accepts most files, but this doesn't make them correct...

The new release is different. It is just 'new' and needs to be tweaked just as v0.2 did right after release. It can open modded files, I don't think you should say it doesn't. That they don't open some files, or (most of) yours is no big deal, I can and will fix that and worst case you need to redo parts of files (you can always export/import chunks between the versions, with a little care). For now, I just need files to test so I can improve the controller definitions and/or parser code. Maybe it will then read your files as well again. When most of these issues are worked out, I'm much more comfortable with S3D being used for public mods, because I know it is better than v0.2 at handling game files.

The past months I've read some issues regarding problems with some mods in the game. Noone ever says, or thinks that v0.2 may be the cause. Not that it is, but it may as well be. Who will know? The fact that the game reads a file doesn't make the file 100% compatible. Then, there's people mixing tools around, which can potentially create more problems. Then, there's functionality in S3D (export/import chunk) that can create even more problems (as there is still alot of hidden data, import the wrong chunk that looks right, and you're in for even more mess). Or incorrectly sorting chunks (by index)... I don't want to tell everyone that S3D is a crappy tool, but you must never forget it is alpha/beta and hence prone to making mistakes. Especially, since the author is human too! I doubt it will ever be perfect. I am not a dev with full access to the game source.

That v0.5 is not stable is no suprise to me, I knew this when I made it public and I clearly stated so in my documentation ;) It is also why I allowed side-by-side operation of the two releases, instead of just one release (which I would normally do). Just give it (me) some time...

To everyone, if you report a problem, please attach/send me files to check. I can then fix problems alot faster. Thanks for the feedback sofar :up:

PS: The number of downloads (79 in 5 days) compared to reports (just the ones above), can mean two things. Either everyone thinks it's a good tool that works fine (mostly), or everyone thinks it's a crappy tool that doesn't work and doesn't bother to report anything... Maybe I'm jumping the gun and the bugs will flood in a bit later though :huh: :rotfl:

skwasjer,

You are doing a great job with the tool. Do not be hard on yourself, you have nothing to apologize for. It is a responcibility of a modder to check/test the mod. If there was a problem with the mod, it would be easy to check whether the tool introduced some undesired changes. There are a few programs around allowing for a comparison of the file BEFORE and AFTER the changes even if someone is not knowledgable in hex-editing.