Don't know if it's appropriate to post this here, but Thanks 1000 times over.
I needed this.

lol
this has to be something messed up with the envelope.

I'm going to do some major surgery on his skeleton. (replace all the bones) I've been itching to try it anyway.
The worst that can happen is he will look stranger.

I got hung up on this poof guy all day. Got it in the hex editor right now. checking things I know and looking for wildly different things.

Aside from the stuff in the last post the only thing I've noticed is he is weighted funny. Most the bf models have a single weight ref and value, even though there are 4 slots per weight. this guy has 2. They all balance to 100%, but the idea is wierd.

Even with the long neck, his head should still be where the normal soldier's head would be though and not 2 feet to his right and on the ground. All the ENVL settings are correct. So the stuff it's weighted and enveloped to are just in the wrong place.

I'll get a small screen in here to see if it's what your seeing.

Can msh's be extracted? Yes and no.
Once extracted, they wont be msh's as we know it. It would be the same as a msh that passes through ModelMunge.exe.
I'm sure the extracted msh could some how be shoe-horned into a lvl file, or even properly munged back in. (I don't know the details of how.) That would require knowing how the bfbuilder tools and all the munge.bat files work.

Yarael Poof.
heh. I'm not certain I loaded him right. I test without skins, so he looked like an angry wad of paper.
If that's his main issue, my first guess is that he is enveloped all goofy.
What animations does he use?

-edit-
I tried the blackfoot repair on him. (for giggles.) It cleaned it up a little, but still has geometry on the floor, not animating, and his arms are placed and animating in strange ways.

The yareal1 chunk (the one with the actual mesh data) has 3 SEGM's in it's GEOM. I haven't seen that before.

His bone hierarchy seems to be intact.

-still digging

Does this guy work in BF2? (can't test that, don't have it.)

The Riley pages have great info.
The many boxes around his sections represent the nesting. Pretty novel, I thought.
All his info is specificly relevant to lvl files.
I got most of my tag info from there, from GT, the Debug Window in the msh viewer, the archived docs in the modding encyclopedia, and from the documented options in the BF1 and 2 modding tools. (I need to update the end of my notes page to reflect my sources)
If he was working at my speed, the Riley pages would have taken years to make.

The msh stuff he does have is refering to how the msh is stored in the lvl file and not the msh's in our asset folders.
It's still points, triangle strips and material info, but a lot of the details, tag structure, and byte encoding are different. Once the assets, scripts and such make it to the lvl, they need to be in a state thats ready to be consumed by the engine as quick as possible. The .msh is still pretty high level and un-optimized (though I was suprised to find triangle strip info).
He mentions some of the directx formats and refers to msdn for further study on them. They make my brain hurt.

The biggest (most inconvienient) difference is that the tags used in the lvl sections of the lvl files have 3 or 4 characters and are not case sensitive. I went crosseyed trying to find that pistol in the ps2 lvl and had to give up till I can dedicate some time to learning all the lvl tags. I seem to remember that some of the info is broken up and stored in diferent areas once it's munged. Like the actual skeleton geometry. Info like that is relevant to whether we can stretch neck bones without making a new skeleton rig.

I see you guys hexing the lvl files and it blows me away. I can't make sense of em.

[spoiler]too many words - too many words[/spoiler]

Right on.
I hope the info helps.
Sorry if it seems unclear at points, been working through severe headaches the last few days.

I like the name 'Blackfoot Repair Kit'
And this asset pack is fantastic. It's come a long way since 1.4.

Blackfoot Repair (kludge)

Blackfoot is the un-intentional appearance of part of the skeleton of a model.
In some cases, it appears on or below the ground, directly between the legs of the character.
Sometimes it is a diamond shape inside the body of the model, and only appears (passing through the body or head,) during animation.

I believe what causes this, is the lack of, or improper FLGS in the skeleton MODL chunk(s).
There may be more to the issue, but this repair will get the blackfoot off the model and the game.

I'm going to ramble about some stuff now, feel free to skip to "Ok. So how do I do that?" to avoid boredom.
Bear with me as I am as good a writer, as I am a programmer. (meh)

First off, What is a MODL chunk?
[spoiler]MODL is a tag inside the msh file that defines geometries, points, and spaces for that model.
There are several types of geometries, and usually many MODL chunks per msh. Each can have it's own skin, shape, and visiblility settings. Those settings are contained in sub tags. To see an example of all these tags, load up a msh in the Starwars Battlefront Viewer and select "Show" then "Debug Window."[/spoiler]

Ok, What does all that mean?
[spoiler]Good question. Some of it is self explanitory, some isn't. I've got a thread on the msh structure [here]http://www.swbfgamers.com/index.php?topic=3905.0. I don't know what most of it means and am learning more about it every day. You don't have to know all about it to interact with it though. (Just like BFBuilder, eh?) Basicly, it's all the settings, geometries, material, camera, translation information, the game needs to render the model.[/spoiler]

What part Fixes blackfoot?
[spoiler]FLGS.
I don't know what setting diferent values for it does. GT has a thread on it and I'll link to it from here.
Browse through a known, good model's debug view in the viewer, and note which models have a FLGS field, and which ones don't.  FLGS will be located after NAME and PRNT, and before TRAN and GEOM.  Almost all the eff_*, bone_*, and root_* MODL chunks have it, while few of the others don't.
Now check the debug view of your model that has blackfoot. I'm almost certain, there are several skeleton pieces (eff_*, bone_*, and root_*) that don't have a FLGS tag.
The fix is to insert a FLGS field into the proper place.[/spoiler]

How will that fix it?
[spoiler]I'm guessing that FLGS has something to do with whether the engine renders a MODL or not. Perhaps it is just a visability setting. An XSI guru can tell you more about that part, cause I don't know.
What I do know is that copyig a FLGS field from a known good model into the skeleton pieces of one with blackfoot, makes the blackfoot go away. So this is more of a kludge than a fix.[/spoiler]

Ok. So how do I do that?
Finally. The meat and bones.

Tools:

   
• A Hex-editor. I use Freeware Hex Editor XVI32 (http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm) and recomend it highly. Also, my instructions are XVI32 specific.
• A calculator. (the math is simple, but absolutely has to be correct.)
• My SWBF_MSH_TOOLS_v*.zip from the bottom of my msh structure notes post. http://www.swbfgamers.com/index.php?topic=3905.0 (They are buggy, but work for this and much more.)

Make a work folder containing the following:

   
• a msh with blackfoot. (You don't need tga's, odf's, or .options's for this, just the msh file)
• a msh with no blackfoot. (any one from the bfbuilder assets will do)
• SWBF_MSH_TOOLS_v*.zip

Setup

   
• Unzip the tools into the folder with the msh's your working with.
• run MSH2chunks_v*.exe
  This will create a sub directory for each of the msh's in the folder, and fill them with .chunk files.
  (The benefit to breaking the msh up is now you don't have to hunt through the whole msh for every MODL)
• Open the folder with the chunks of the model with blackfoot.
• make a new folder in this folder.
  The name isn't important at all, new folder is fine.
• select all the MODL chunk files with bone_ root_ eff_ sv_ or DummyRoot in thier name.
• COPY them to the new folder.
  It will seem like all of them, but some should be left out of this. (l_hand, r_hand, helmet, head, pack, ect.)
• Open the folder you just copied those MODL chunks to and one at a time, open each one with XVI32 and see if it has a FLGS field. Delete the ones that do. (this is why we copied them)
  It will be within the first 100 characters in the file, 12 bytes(spaces) before TRAN.
  At the end of this step you should have a folder with only the pieces that have no FLGS field.
• Go to the folder with the known good model's chunks and open it's DummyRoot chunk with XVI32.
• Click once on the "F" in FLGS on the right hand panel.
• Hold SHIFT and use the cursor keys to move right 11 spaces.
  This will mark the characters red. You should have 12 spaces marked (from the first 'F' to the space just before 'T' in TRAN)
  hit ctrl-c to copy the block to the clipboard.
• close the DummyRoot chunk and go back to the new folder with all the FLGS-less chunks.

One at a time, open each chunk with XVI32 and do the following:

   
• Click tools, then Data Inspector. (Make sure the data inspector is visible, we need it)
• Click on the first 'T' in TRAN and press ctrl-v.
  This will insert the FLGS block and should insert, not overwrite anything.
• Since we just added 12 bytes to the size of this chunk, we need to adjust its size header acordigly.
  Click once on the 5th space from the begning. (dec. offset 4) It will be the first space after MODL.
• On the Data Inspector, double click the number after 'longint' to bring up the encode number dialog.
• Make sure the 'lonint(4 bytes)' option and 'Overwrite at current address' option are selected.
• Add 12(the size of the FLGS chunk we just inserted) to the number and type it into the number box. (don't copy and paste the number or you'll have to open the good DummyRoot again to get the FLGS chunk back on the clipboard.)
• Press OK, to overwrite the old size with the new.
• Save the chunk and open the next one.

Ok, now you have a folder full of 'fixed' MODL chunks.

   
• Count the files you just fixed.
• Multiply that times 12.
  That is how many bytes you just added to the model size.
• Now we need to add that to the HEDR and MSH2 field.
  Go to your blackfoot model's chunk directory and open the first file. (HEDR)
• Click once on the 5th space from the begning. (dec. offset 4) It will be the first space after HEDR.
• On the Data inspector, double click the number after 'longint' to bring up the encode number dialog.
• Make sure the 'lonint(4 bytes)' option and 'Overwrite at current address' option are selected.
• Add the number from the previous step to the number in the box and press ok and save. (it's ok to copy/paste to and from the calculator now)
• Do the same for MSH2 (the second file in the directory.)
  The numbers will be different.

Time to put it all back together.

   
• Copy all those fixed files back into the model's chunk directory. (overwriting the existing ones.)
• Copy or move the Chunk2MSH tool into this directory and run it.
• This puts all those pieces back together into a new msh file named "new_msh.msh"

Have a look at it in the MSH Viewer. If nothing shows up, then something is wrong with a size field somewhere. (most likely HEDR or MSH2)

Now rename the file, munge and test the msh in Battlefront.
If Battlefront crashes, then one of the 'fixed' MODL chunks probably didn't need fixing. Make sure you only did the bone_ root_ eff_ ones and not any of the actual geometry ones like 068_MODL_054_l_hand.chunk (note, no root, eff, or bone in it's name.)

Thats's it.
If it's working, rename it appropriatly and add it to your arsenal of assets, and delete the chunk work folder.
If it isn't working, go over the steps again, if it still isnt working, feel free to ask questions.

NOTE
I updated the chunk2MSH tool. If you are using "chunk2MSH_v2.exe" then you don't need to preform the purple steps. The program does it for you.

-edits-[spoiler]
11/22/2011 -marked un-needed steps, due to tool upgrade.
[/spoiler]

got it.

File name: Qui-Gon_no_blackfoot.rar
File size: 1.56 MB
http://www.megaupload.com/?d=EI7R9WVY

Blackfoot gone.

I'm going to review some of the BF2 models. All these guys with blackfoot has me wondering if it's a feature dropped in BF2 altogether, or just a glitch in someone's exporter. They were also 'missing' (don't know if they were ever there to begin with) the post-MSH2 stuff, like SKL2, BLN2, ANM2, and the first one was missing CL1L. I'm guessing its an exporter issue, but don't know it it is the MSH Viewer, or the XSI one.

All these models have a very simular, Jedi body, so it might just be a problem with this body.

If you run across any more with the blackfoot, post them here and I'll fix them, but I'm also going to try to do a how-to today to spread some of the hex-love.

got it.

File name: gran(old version) (visible bone_ribcage fixed).rar
File size: 117.73 KB
http://www.megaupload.com/?d=ZE8QYMNC
(msh only)

I accidentaly 'fixed' the granmodel4 and BF1 choked(munged fine though), so not all the MODL chunks need to have a FLGS field.

On that same note, I'm testing in the actual game, not sptest, so I have no idea if these msh's are throwing errors in it or not.

re:GT searches.
That was more of a jab at the site. It was terribly inconvienient when I started out and all the answers I read were filled with 'use the search' replies. Their noob control almost turned me off of BF modding altogether. But they have since opened the register function again, and I figured out how to search their site via yahoo and google. (still haven't registered though.)
More for the site than the users though, as they have an incredible amount of information and a lot of hard working modders over there.

The ultimate aim of my tool is to enable just these kind of fixes AND to facilitate experimenting with crazy values without having to swim through to much hex or forums that wont let you search without signing up. So a write up on this fix is enevitable. (once I figure out how to explain it.) The main thing keeping it back is automaticly updating the size fields in a way that is transperant. IMO, having to adjust sizes for every edit is what makes hexing so intimidating.

I'll have a go at the Gran. The blackfoot I can do pretty quick. (tomorrow sometime)
As for adding the fixed ones to your pack, cool, I'm honored. Don't sweat crediting me for the fixs though, I'm just in this for the fun. I'd be more worried about the original authors.

re: neck stretching.
For me it would start with isolating the points in POSL, then shifting them up and testing.
The skin would stretch as well and might need to be tweaked to accomodate that.
I haven't a clue on how to stretch a bone. No GEOM in the bones, just TRAN , NAME, and MATI. But I'm certain that it can be done.
If there is anything else, then it would have to be discovered from there.
(like if it messes with collisions, looks natural, ect)

I have succesfully moved points within a POSL (MODL chunk) without crashing or messing up envelopes, skins, or animations.
But it took all day (12+ hours) to isolate the points, cycling between the msh viewer, hex editor, and 3d object converter.
That was just to isolate the head.  The last 6 hours were spent on the neck, and I ended up cutting to much out.
It was after doing just that, that I decided a gui msh editor was needed for me to accomplish my dream of a better Tusken army. (without learning XSI.)

Got it.

Same with these guys. No FLGS field, so I pasted it in.
Didn't use XSI on this. (Haven't opened it in 2 months.) Used my little msh2chunks tool, edited the chunks individually(with a hex editor) and then used chunk2msh and tested in my development/scratch level in bf.
(those tools are at the end of my msh structure notes. I'll make a proper post for them once they are more stable and documented) http://www.swbfgamers.com/index.php?topic=3905.0

I did use my msh edit program to quickly look at the tag structure. I havent released it yet, because it is still very very hackish and buggy. But wingrep verified the non presence of the tags as well.

The trick was rembering how many chunks I edited so I could properly update the MSH2 and HEDR.

File name: KitFistoCinDrallig_no_blackfoot.rar
File size: 3.54 MB
http://www.megaupload.com/?d=K6FY7A50

-edit-
I'm still not 100% happy with these msh's.
There are several addon geometries and I'm not sure the absence of FLGS was the actuall prob. (The bones were nested pretty strangly compared to other msh's.)
I'm pretty sure there is a way to combine and properly name the textures.  (name is simple, but adjusting UV is not)
Fisto's weave animation(lack of it) bugs me, but I'm just glad he made it to BF1 at all. (after dealing with geometry outside of XSI, next is animations.)

Since I don't have answers to the above, I'll just have to promise to re-visit them in the future.

Awsome!
Thanks, Phobos Developer!

Must be download day at swbfgamers.

I havent played with a flame thrower ouside of the one in bf2. (playing, not modding)
I can't imagine my Tuskens using one, but the Bestine security forces hanging out in Fort Tusken might enjoy it!

Groovy.
They will be put to good use.
Thanks, WUSIEsS.Target.

2 pieces.
So far, I got the big, irregular piece out.
There is still a diamond shaped one left.

The pelvis was missing the FLGS section in it's MODL chunk.
I suspect thats what is wrong with the other piece, but I'm going to scan through all the MODL's to be sure.

-edit-

FIXED
I compared the tag structure of the MODL chunks to that of tat_inf_tusken.msh (It's what I had on hand at the moment) and saw that almost the entire skeleton for rep_hero_quinlan.msh were missing the FLGS field.
I pasted the FLGS field from the Tusken pelvis, to just before the TRAN field in 33 skeleton pieces (adding 396 bytes to the filesize.)
Doing just the pelvis left a piece, thats why I did all the things.

I don't know what the FLGS field does.
But it is apperantly important to BF1.

http://www.megaupload.com/?d=GWX3169E

Forgive the randomness, I'm currently swimming in GUIctrlID's to flesh out my msh editor, so I'm unable to push mapping right now, but I can offer some ideas.

I dig the zombie bespin map as single player, is it online compatible?
If not, then there is idea 1.

2. A destructable (not capturable) zombie spawn point. (cave in to stop/slow the flow of zombies,  or a large explosion that effectively ends the zombies, the source of the zombies, the player(s), and map)

3. since zombies vs droids doesent make sense (no brains to eat) how about giving the zombies HealthType = "droid" so zombie specific damage can take place. (anti-zombie flash grenade,  anti-zombie bullets/bolts, anti-zombie arc zapper thing.)

4.For locations, you got all the bases covered. Anything else would be a variant.

• Desert zombies. (Tusken vs Zombie Tusken/Jawa/Humans might be interesting.)
• For a real-ish variant, how would native americans or ancient incans have handled a zombie outbreak?
• Deathstar. (Accident in one of the lower levels that would have to be contained by lowley Stormtroopers and perhaps even Vader himself. (Would force choke work on a zombie?)
• Really any battlefield where there were plenty of dead, with a small group of survivors would make for a ready made zombie playground. Remove the vehicles, and make the locals and both factions into zombies. (Geonosians come to mind)
• A military ship at sea, a sub, or a space station. I'm imagining a small, closed in map, like a ship with narrow halls and few open areas and a low ceiling.  Every corner could turn into a fight for life. Basicly shooting for the doom 2 type of areas. With the right lighting it got quite spooky at times (once you got in to it.)

5. Zombie Hero. Any chance of 'special' zombies that do more than creep and kill? Like a Zombie Jedi / undead witch doctor that could still wield force pull or something simular.

6. custom zombie sounds. grunts, gurgles, mumbles and the sound of meat dragging.

I'm tapped for the moment.