[REL] ObjectCtrlsRef add-on for S3D

[Madox58]

This add-on will allow the editing of the ObjectCtrlsRef controller in the .FX files.

The instructions are in the included Read_Me.txt

http://www.mediafire.com/?8u2veno3m4jg2qt

[TheBeast]

Nice work.. I have often wondered about changing the file extension from.FX .DAT and checking if S3D could read it but never found the time to try it.
Now with this NEW SHController added in, will I be able to adjust wakes and other effects? Or does this just add the missing Nodes?

[Turtle01]

Great !!!

Greets
Turtle

[Madox58]

This just adds the ObjectCtrlsRef for now.
I'll have other adjustments to S3D done soon.

[Madox58]

OK!
You can use S3D to edit the Ship Wakes in SH5 with this addition.
Place the _SH5 folder in the 7z file in the Controllers folder of S3D and your good to go!
:up:

Does NOT affect SH3 or SH4 ShipWakes!

I'm working on other Controllers now and sooner or later they will be rolled into a complete package.

http://www.mediafire.com/?bsb5c697chgv76e

[TheBeast]

OK!
You can use S3D to edit the Ship Wakes in SH5 with this addition.
Place the _SH5 folder in the 7z file in the Controllers folder of S3D and your good to go!
:up:

Does NOT affect SH3 or SH4 ShipWakes!

I'm working on other Controllers now and sooner or later they will be rolled into a complete package.

http://www.mediafire.com/?bsb5c697chgv76e

This still requires changing the file extension to .dat for S3D edit?
Then after saving changes made, change the extension back to original extension when done?

[Madox58]

NO.
S3D will read the .val file as is.
I'm working on the FoamWave now to complete the set.
;)

If a file uses the .dat .val .zon. cam .dsd or .sim extensions
you don't need to rename them.

[Madox58]

Could someone open an SH4 ships .val file and check the FoamWave setting?
I'm getting an error with the stock S3D file.
:hmmm:

[TheBeast]

I created a new mod folder structure and copied data\Submarine\NSS_Uboat7c\Submarine Parts\Conning_7C_02.fx to the new mod as Conning_7C_02_bak.dat adding "_bak" just in case of possible legacy issue's. I did the same for Conning_7C_01.FX to be used as blueprint. Source files already include the SubFlags MOD by TheDarkWraith.

I just edited the Conning_7C_02.FX file, adding the missing Wakes/Splash nodes.(Copy/Paste from Conning_7C_01.FX)

When I tried to verify changes using Goblin Editor I get the following errors that look like parent ID's do not match.
http://www.subsim.com/radioroom/picture.php?albumid=255&pictureid=2566

I was hoping all Parent ID's would be the same for both Tower 01 and 02 like it was with SH4 towers.

I am stuck at this point until I figure out how to find the Parent ID's...:damn:

How do you like the title for the second part of the error...:hmmm:

[Madox58]

Parent ID's in Goblin show up kind of backwards.
:doh:
S3D also does a backwards Hex ID.
:hmmm:
Let me take some screenshots of
Goblin ID's,
S3D ID's
True Hex ID's.
:yep:

Then I'll post a 'How Da Heck we figure dis out?' thing.
:haha:
It is confuseing as all get out for most non-hex people.
So I'm not insulting anyone!
Once you see the ScreenShots?
You'll see how confuseing it can be!
:nope:

But I'll have you working like a Pro in no time.
:yeah:

[thfeu58]

Another thing which fits maybe, nevertheless, here on this subject occupies me over and over again once.
What get the anti-aircraft of the boats to aim too deeply?
Thus the anti-aircraft occupying can never shoot an airplane of the sky!
I have already looked in all possible files, but have not found the cause yet.
Is it possible, in the end that the Y axis of the models can be the cause? :hmmm:

[Madox58]

The Axis of the base 3D model 'might' cause low aiming.
I'd rather wait to actually look at the files before I stick my foot in my mouth.
:haha:

[Madox58]

And I found a weirdness in the files.
:hmmm:
Goblin tells me true or false.
But the same file in Hex uses a different value?

[TheBeast]

Sounds like Goblin may have some type of built in decription logic.

[Madox58]

Goblin shows a True or False,
Hex tells me it's a differnt way of claiming True or False.
Now I have to figure out how to tell S3D it's a True or False statement.

[thfeu58]

What I mine is that
a. the base axes of the airplane models are not concentric of the model by which the flight altitude is higher around the difference,
or
b. the base axes of the anti-aircraft are not concentric of the model by which the purpose deviates around the difference.

And I found a weirdness in the files.

Which file do you mean? :hmmm:

[Madox58]

Here's 3 screen captures of the NTRW.fx file spot lighting the same ID.
Goblin:
http://i108.photobucket.com/albums/n12/privateer_2006/Tools/Capture001.jpg

Hex Editor:
http://i108.photobucket.com/albums/n12/privateer_2006/Tools/Capture002.jpg

And S3D with the FX file renamed to dat:
http://i108.photobucket.com/albums/n12/privateer_2006/Tools/Capture003.jpg

Look at Goblin first,
The numbers
27 9F 67 A6 -73 09 92 48
are the Parent ID of the ObjectCtrlsRef node.
Hex,
the numbers
A6 67 9F 27 48 92 09 73
is the same Parent ID.
S3D,
The numbers
73 09 92 48 27 9F 67 A6
Is also the same Parent ID!

Notice Hex and S3D are just backwards from each other.

Now look at Goblin.
Backwards AND cut in half with the halfs swapped!

[Madox58]

I also noticed some Ships FX files list the ObjectCtrlsRef as a Type 10/1000
instead of a Type 10/-1

Not sure what this is all about.
:hmmm:

[BIGREG]

:salute: Hi Privateer

In the beginning , I had problems whit the ID parents , when i enter them directly via S3D :hmmm:, I had to add the dials through Goblin Editor for the return properly (even when trying all the adjustments at the registration) , have you an idea for that ? , and I saw he missed the SHcontroler Dial "81" -> "10thGyrocompass"

[Nisgeis]

Look at Goblin first,
The numbers
27 9F 67 A6 -73 09 92 48
are the Parent ID of the ObjectCtrlsRef node.
Hex,
the numbers
A6 67 9F 27 48 92 09 73
is the same Parent ID.
S3D,
The numbers
73 09 92 48 27 9F 67 A6
Is also the same Parent ID!

Notice Hex and S3D are just backwards from each other.

Now look at Goblin.
Backwards AND cut in half with the halfs swapped!

Hexadecimal numbers are usually stored with the low byte first, then the next byte up then the third byte up (etcetera, depending on the length of the number) and finally the high byte. For 32 bit numbers, they are represented by eight hexadecimal characters, so A6 67 9F 27 48 92 09 73 is two 32 bit numbers (or one 64 bit number, but it seems they are actually two 32 bit numbers with the colon in GobEd). So A6 67 9F 27 48 92 09 73 becomes A6 67 9F 27 and 48 92 09 73 which when ordered correctly become 279F67A6 and 73099248. If they actually represent one 64 bit number then the correct number is 73099248279F67A6 (as S3D puts it), but if they are two seperate 32 bit numbers then the correct number is 279F67A, 73099248 as GobEd puts it, as each new number starts again from the lowest byte. In this case the two lowest bytes would be A6 and 48. If it were only a single 64 bit number the lowest byte would be A6.

[TheDarkWraith]

Privateer's method of reading the ID is correct :up: In the hex files it is one 64 bit number but in Goblin it is split into two 32 bit numbers.

[urfisch]

looking forward, to get some new controller stuff for s3d! still got in mind to change the fx effects, but i surrendered when i saw goblin rewrites my modded controller-data after opening. so they become useless in s3d.

the story is, month ago i released some beta stuff to change particle controllers in s3d for sh5. but it had the mentioned "bug". means: you can only change the controllers in s3d and save them successfully. but when opening it in goblin, to see the effects...you see the changes, but the data is crypted for s3d - not moddable any more. this way i lost work of days and stopped the progress.

maybe the mentioned 32 and 64 bit case is the problem.

[Nisgeis]

urfisch, did it get corrupted on opening, or only after being saved?

[SteelViking]

Heck, I keep getting corrupted memory after adding controllers in Goblin itself. If you add the controller "lightspace" under grannyloader (it is a controller for ambient light cast on an object) it will work just fine, and you can see the changes in game exactly as you make it. But, upon trying to reopen the .sim later, you get corrupted memory every time. Lost a decent amount of work thanks to it.

[Madox58]

Can you give me a link to D/L the sim that is corrupted?
I'll compare it to stock and see what the problem is.

[SteelViking]

Can you give me a link to D/L the sim that is corrupted?
I'll compare it to stock and see what the problem is.

Here you go, filefront is down, so I used rapid share. Specifically what I did was, I added the lightspace controller to needle 01 and needle 02, because for some reason they only show up whitish silver, and I would rather have them black(I am trying to perfect every detail I can for my interior mod).

http://rapidshare.com/files/408200620/Room_DER.7z

Oh wait, that .sim also had all the dial fixes that BIGREG has done, plus some other changes that I have done. Standby for stock with just the changes I listed.......

Here, stock with just those two controllers added, sorry about my mix up:

http://rapidshare.com/files/408203926/Room_DER.7z

[urfisch]

urfisch, did it get corrupted on opening, or only after being saved?

i think on opening it in goblin. it was fine when just opening it in s3d, with my modified controller files for s3d. but after opening it in goblin, it was crap.

[Madox58]

@urfisch,

Your files for the Particles won't open them for me.

Were the particles stuff updated in one of the patches?
I know where the problem is but have not added the needed lines to adjust it yet.

File date is 3/15/2010 on both.

[Madox58]

Here's a beta FoamWave adjustment.
http://www.mediafire.com/?m9icqi8fpmsairv
Place it in the EnvSim folder of S3D.

Stock FoamWakes have a setting that looks wrong in hex or S3D.
I added a new FoamWake in Goblin and the new setting looks OK.
I then changed the weird settings in S3D then re-opened in Goblin.
So it "seems" OK.
Someone will have to test this version and test in Game.

[Madox58]

Hexadecimal numbers are usually stored with the low byte first, then the next byte up then the third byte up (etcetera, depending on the length of the number) and finally the high byte. For 32 bit numbers, they are represented by eight hexadecimal characters, so A6 67 9F 27 48 92 09 73 is two 32 bit numbers (or one 64 bit number, but it seems they are actually two 32 bit numbers with the colon in GobEd). So A6 67 9F 27 48 92 09 73 becomes A6 67 9F 27 and 48 92 09 73 which when ordered correctly become 279F67A6 and 73099248. If they actually represent one 64 bit number then the correct number is 73099248279F67A6 (as S3D puts it), but if they are two seperate 32 bit numbers then the correct number is 279F67A, 73099248 as GobEd puts it, as each new number starts again from the lowest byte. In this case the two lowest bytes would be A6 and 48. If it were only a single 64 bit number the lowest byte would be A6.
That's me talkin to myself in my head sometimes Mate!
:haha:
Excellent technical explanation.
:up:

I posted the qiuckest way I could that most people can see,
and understand,
right off the bat.
I doubt most care why/how it works?
Just that it does.

I'm sure you understand why I posted the images and info as I did.
:yeah:

[urfisch]

@urfisch,

Your files for the Particles won't open them for me.

Were the particles stuff updated in one of the patches?
I know where the problem is but have not added the needed lines to adjust it yet.

File date is 3/15/2010 on both.

i will have a look on them tomorrow. i just updated the files for the particle controllers in s3d. maybe i did something wrong...im no coder!

;)

[Madox58]

Doing this stuff in S3D is new to me also Mate.
:doh:

Infact?
You gave me the needed push to attempt this.
:salute:

So don't sell yourself short just yet!
:yeah: