[skwasjer]

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

Originally Posted by Navarre

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.

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

Originally Posted by leovampire

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.

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.

Originally Posted by leovampire

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?!

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.

Originally Posted by leovampire

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.

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.

Originally Posted by leovampire

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.

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...
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

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 :rotfl: