This world is smaller now.

Good Journey, Bamdur.

Sounding like the deployable boxes here.

Reminds me of the deployable decoy / hologram from Duke Nuk'em.

Even if you can't control the deployed AI, you still have something to grab attention with.

And deployable barricades sounds fun, as long as the map doesn't get crashy.

!

Will the vehicle be drive-able?
Will it work for Multiplayer?

I am intrigued.

So, I'm working on that msh format structure and I'm running into some incredibly large numbers.
Not large as in milllions and billions, but large as in 15, 20 and more places to the right of the decimal.

Does anyone here know (or even have a guess at) how precise XSI is with things like point locations?
I know the units are usually 3.something tall (approximatly). Just don't know how important that 10th or 11th decimal place is.

I Have the prog, just not installed and am hoping to save a few hours.

-edit- just realized this isn't really the proper place for this Question.
Feel free to move it to Mod Factory or Requests.

-edit
After a lot of trial and error with raw data conversion, I have determined that it is quite safe to use a precision of 6 decimal places.

The nature of floating point numbers (if I understand the IEEE spec correctly) is that the number should be reproducable with a minimum of 9 decimal places.

Of course, most systems are much more acurate than that, but knowing that minimum gives me a boundry to work with and keep my numbers at a sane length.

As a result, I will use 9 places in all my calculations, and only display however many are contextually appropriate and readable.

0.900000000 is just not right to display 90%.
0.90 is better, in that case.

For vertecies, normals, uv locations, rotation quaternions, excetera...,  the 9 places should be more than precise enough.

edit by tirpider: tagged title

Just searched my archive, couldn't find it.  (I have a small archive though)
Do you know the mod-id for it? (ie, bes1)
Most of my maps only have the mod-id as the filename and it doesn't appear to be in the 'p's.

-edit- spelling fix

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.

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.

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

pretty sure it's just /sideselect without anything after.
Thats how the ps2 server is.

heh. I don't see why not.

We could put them in game without textures and call it "Angry Wads of Paper"

It's 100% a weighting problem.

I isolated the head SEGM and it's weights.
It starts off with the spine, works it's way around the neck then to a hand, then the other hand.

I thought I was looking at the wrong wght section. nope, triple checked.

So, the fix is to go through and re weight this guy. the envelope parts seem ok (by my untrained eye.)

I'm going to try to do the head by hand (527 points, so roughly 1054 edits), then see if I can make a somewhat automated process for the others.
(or at least a way to get the #'s into a spreadsheet then back again)

This might take a couple of min.
(by min, I mean days, and by couple, I mean a whole bunch of)

Just took him for a test drive.
This is a good technology.
I like this a lot.

Thanks, Sleepkiller.

Winrar is throwing an error on the zip.

!   D:\Games\SWBF\_work\Player Model Assets\_in\ghostjedi.zip: Unknown method in jed_inf_jedi.msh
!   D:\Games\SWBF\_work\Player Model Assets\_in\ghostjedi.zip: Unknown method in jed_inf_jedi01.tga
!   D:\Games\SWBF\_work\Player Model Assets\_in\ghostjedi.zip: Unknown method in jed_inf_jedi_low1.msh
!   D:\Games\SWBF\_work\Player Model Assets\_in\ghostjedi.zip: Unknown method in readme.txt

It seems to like the option files.

-forgot to mention that I tried re downloading a few times. same every time.

I love the idea.

Perhaps a local faction, "haunting" a ghost ship, battleground, city, ect?
Or even helpers in Phobos Developer's zombie levels?

My wife ,who not only tolerates my SW geekery, but actively encourages it.