Override Texture-able Ep3 trooper

[Snake]

I think this is done with Hex Editing but I don't know how to do it.. Could someone do it, or show me how?

[tirpider]

My communication skills are awful.
Bear with me and ask questions if I am unclear.

OverrideTexture for a SWBF msh

IN THE MSH:
The MODL thats going to be overridden needs to be named:
override_texture
-or-
override_texture2
3, 4, 5, ect, don't work.. 2 is the limit

THE .OPTION
The .option needs to have the following:
-keepmaterial override_texture
-or-
-keepmaterial override_texture -keepmaterial override_texture2

IN THE ODF
These lines override the default texture:
OverrideTexture = "wookie"
OverrideTexture2 = "wookieface02"
It's just the texture name without the .tga extension


The only part that needs explaining is how to edit a string in a msh
(ie, how to find and change the MODL name)

You need 3 tools for this:
A hex editor - XVI32
My MSH INFO TOOL - SWBF_MSH_INFO
My Tag Size Validator - MSH_TAG_SIZE_VALIDATION_TOOL

FINDING THE MODL NAME
Load the msh into the MSH INFO tool.
It will give you a tree view and all the MODL names
We are looking for the one that has all the geometry data, I won't go into how to identify all that.
It will be the one that has a different name style than the rest.
Most are called bone_, or root_,... those are skeleton pieces.
The one we seek is close to the top, right under DummyRoot.
Not sv_*. Thats a shadow volume.
The other one.
rep_inf_ep3trooper

make a note of that and close the tool.

Groovy, now that we know what we are looking for, open XVI32 and load the msh.
click Search > Find
and type
rep_inf_ep3trooper
into the search dialog then hit ok.

the first one it finds will be a .tga reference.
thats not what were after.

hit F3 to search again.

the next one appears after a NAME tag.
This is it.

Make sure XVI32 is in insert mode.
(tap the insert key and a box on the status bar of XVI32 will indicate either overwrite, or insert)
make sure the cursor is positioned on the first letter of the rep_inf_ep3trooper string and type:
override_texture

Now, hold shift and use the right cursor key to select rep_inf_ep3trooper
Once it is all hilighted red,
release the shift key,
then click on the delete button on the XVI32 toolbar.

you should have 2 empty spaces after override_texture
Those are nulls.
We need to ensure that the length of the string plus the nulls is evenly divisale by 4.

Click on the first character of override texture, hold shift, and move right, to select override_texture and the nulls.

If the data inspector isn't visible, click Tools > Data Inspector to bring it up.
Check the block size in the data inspector.

It says the length of the hilighted data is 18.
Not evenly divisible by 4.
We need to add 2 more nulls.

Tap once on the shift key to clear the selection.

Click once on the first 00 entry after override_texture on the left panel.



we need to add 2 nulls, so type 0000
(zero,zero,zero,zero)

The string is changed.
We aren't done though.

We need to check to see if anyone was parented to this MODL.
So hit F3.
Yep, found it again.
the bone_root is parented to the chunk whuse NAME we just changed.

Not a problem.
Just change this the same way.
Be sure to make it's size a factor of 4 by padding with 00's

Search again..
That should be it.

Save the file and close it.


One last step.
Run the MSH_TAG_SIZE_VALIDATION_TOOL.exe.
It will ask what file you want to run it on.
It will then scann the file for any size fields that need to be updated.
What we just did would normally need 6 more edits to fix the sizes.
This tool does them for you.
If it finds any size errors, it will offer to correct them.
Then it will offer to save a report.

Correct them and save a report if you wish.

Thats it.

This example wont have any corrections but most edits do.

the same method can be used to change any string in the msh.
Like TX0D (textures), NAME (a chunk Name), PRNT (a MODL's parent), CTEX (cloth texture)
Just remember to make it's size divisible by 4 and run it through the Size Validator .

It's ready to munge

[Sereja]

Not sv_*. Thats a shadow volume.

Can you explaine more about this? I mean, is that possible to edit shadow with hex editor? For example remote droids has human shadow, and R2D2 do not have shadow at all. Is that possible to fix that?

[SleepKiller]

Can you explaine more about this? I mean, is that possible to edit shadow with hex editor? For example remote droids has human shadow, and R2D2 do not have shadow at all. Is that possible to fix that?

They are the low setting shadows, a simple projected TGA. He is referring to shadow MSHs that are used when the games shadows are at high settings.

[tirpider]

Can you explaine more about this?

Shadows are a whole different can of worms.

There are SHDW shadows, that are really wierd and I don't completely understand.
There are sv_ shadows that are just non-skinned, low-poly versions of the model.
There is the shadow that modelmunge.exe creates from the hi-res model.
Then there is the shadows created by ZeroEngine itself.

There are many reasons for all the different types, and I only have a handle on some of it.

The sv_ shadow volume is the easiest to explain.

sv_* means that it can have any name (*) but it must be preffixed by "sv_" so that modelmunge.exe knows what to do with it.
It is a low-poly version of the model. Not as low-poly as the lowres version of the model, but pretty low.
It is enveloped if the model is animated.
It is not skinned (no UV0L chunk), though  I have run across some that are. I don't think the UV's on the shadow volume do anything. They just don't break anything so the original devs left them in place.

The art guide* in the bfbuilder documentation suggests that the sv_ should follow the shape of the model as close as possible, without crossing to the outside of the model's mesh.
(A LOT of the SWBF assets have shadows that cross outside the model's mesh, that's why they look wierd in viewers that don't parse the hidden FLGS. sv_'s should always have the FLGS set to 1, just like nulls, hardpoints and bones.)

If you look at the shadow of several models in game, you can tell who is using a generic clone trooper shadow, and who has a custom one.
You can also tell if the model has no sv_. The shadow in-game will look like a faint blob of shade.

R2D2 do not have shadow at all. Is that possible to fix that?

To give a shadow to a model that doesn't have one, you have 2 choices (that I know of)
1 - make a low-poly version of the model and merge it with the msh
2 - let modelmunge generate the shadow by putting "-hiresshadow" in the .option for that model.**

I have kitbashed some shadows together, via hex-editing, and it is time consuming and confusing.
If you must put a sv_ into an existing msh, I recomend building that shadow in a model editor, then hex the chunk in later.
Still pretty involved, and requires fiddling about with weights by hand.
There is no pretty answer for that route.

I have wondered about using the main mesh to generate a shadow, instead of the low poly shadow mesh.
In fact... since I don't have a low poly head for Talz, I'll try to use the Hi-Res mesh as a shadow.
Otherwise he will have to keep using the old wampa shadow, which looks wierd.

remote droids has human shadow

I think the remote having a human shadow is from the game logic and not the model.
It's probably hard coded to use the shadow of the player.

To test:
Play as a sniper
Launch a remote and check your shadow.
Do it for Rebels, and CIS.
If the shadow for the CIS sniper's remote is a droid, then we know it's the game.
Can't fix that without exe hacking.
I wouldn't recomend it.



* BFBuilder\Documentation\artguide.htm , Appendix B
** BF2_ModTools\documentation\misc_documentation.doc

-edit and comment.
I'd like to work the earlier post on making a msh override texture compatible into a tutorial, but I sometimes have trouble being clear and to the point.
I would love it if anyone would like to help revise the instructions.

(lesson of the day: stay in school )