Someone with a decompile tool?

Started by Snake, December 01, 2011, 01:24:35 PM

Previous topic - Next topic
Could someone decompile the Ewok and freeze it into a static prop?
=AaTc= Forever

SALLY....

-Retired Modder

Both Ewoks saved in the viewer.
(both so you can have the gray and the brown one)

December 01, 2011, 03:20:57 PM #2 Last Edit: December 01, 2011, 06:56:31 PM by SnΛke
Quote from: tirpider on December 01, 2011, 02:31:17 PM
Both Ewoks saved in the viewer.
(both so you can have the gray and the brown one)

Awesome! I will try them out when I get home, I appreciate it!!

--EDIT

Those are great, thanks! Could you do the same to some alliance ships? You should make all units and vehicles like that and release them...thatd be amazing. :D
=AaTc= Forever

SALLY....

-Retired Modder

Better yet... ;)

Turn any msh into a static prop:

Get SWBF MSH Viewer
here or here

1. load the model(msh) into the SWBF MSH Viewer
2. select 'file / export' and save as a wrl file.
3. load that wrl file into SWBF MSH Viewer
4. select 'file / save', and give it a meaningful name.
done.

Might be easier than uploading all the sides as props.


December 02, 2011, 01:39:34 PM #4 Last Edit: December 02, 2011, 08:37:01 PM by SnΛke
i <3 tirpider (no homo xD) thanks!

--EDIT

It works but after I save it as an msh it shows up with no texture in msh viewer. It has the textures with it.
=AaTc= Forever

SALLY....

-Retired Modder

December 02, 2011, 09:09:10 PM #5 Last Edit: December 02, 2011, 09:30:34 PM by SnΛke
Alright so heres the problems I have:

Some models crash msh viewer right after it makes it into a wrl
The models never have texture in msh viewer after they are changed to msh
When munging it says they have no collision geometry

Fixes?

--EDIT

I figured out the texture problem but when i change the ATAT to a prop it doesnt come with the textures. It crashes right after export.. idk why
=AaTc= Forever

SALLY....

-Retired Modder

December 02, 2011, 10:58:00 PM #6 Last Edit: December 02, 2011, 11:29:06 PM by tirpider
I don't know what is causing the msh viewer crashes.
The person that wrote it is kinda like me, writing a prog without the benefit of a documented file structure.

(Well, better than me in that I have no hope of ever rendering anything in my basic progs)

The ATAT also happens to be the biggest, buggy-est model in the game, as well.
(I don't know enough about validating the msh data yet to confirm or fix it.)

After you save the wrl as a msh, it should use the same textures it did before.
I think the viewer changes the file extension to png for the wrl's then back to tga for the new msh. copying and converting them if they were in the same folder the model was loaded from. (It did for the ewoks at least.)

Putting the original textures in the same folder as the new model, then loading it into the msh viewer should work.

Regarding the no collision/munge error.
You'll get that.
It's seems every other model gets that error, but most all seem to work in-game.
To be safe you need a .option file for the .msh

In that .option file needs to be the following line:
-nocollision
Then name the option file appropriatly.
for example,
new_msh.msh
would need an option file named,
new_msh.msh.option

Munge might complain, but it should work out.

(I'll test out the ATAT real quick, I'm not set up to test it in-game though)

-edit-

The exported msh version has no tga materials listed in it.
It still has UV info for the diferent segments.
I'll try forcing it's old materials into it. (Kinda like stuffing a turkey, but not really)

-testing-

Well... It seems to work in the viewer with the stock textures now. (without causig the various stack overflows and exceptions.)
Can't say if it will work in the game or not.
It will certainly never walk again.

no textures in the rar, just the hobbled atat.

Alright thanks a lot! This will be extremely useful!
=AaTc= Forever

SALLY....

-Retired Modder

Heres a little tip i learned from experience. In xsi there collision primitives and meshes named accordingly, if a prop that was made in xsi has no collision primitives or meshes, then the munger will give the error no collision geometry. If this happens the munger uses the props bounding boxes which usually gives accurate collision. but for bigger props collision geometry might be necessary. Say you needed special blockage in certain areas, or it might be too much for the munger to create its own collisions for, as a result it could be buggy. thats where the msh.option -nocollision comes in. It tells the munger to not make its own collision, but to use its collision primitives and meshes. though i may be wrong, im pretty sure this is how it is. it has been a while since ive dealt with it

so does classlabel affect collision?