[tool]MSH_TAG_SIZE_VALIDATION_TOOL v1.0

[tirpider]

MSH_TAG_SIZE_VALIDATION_TOOL v1.0
by tirpider@yahoo.com

A Star Wars Battlefront 1 & 2 model utility.

visit http://www.swbfgamers.com/

This tool is an aid for hex editing.
It will look for tag sizes in any SWBF 1 or 2 .msh file you select, and determine if they are valid or not, offering to repair them if they are incorrect.

USAGE:
It is simple to use.

1 - Double click on the executable.
2 - Select a .msh file.
    The program will take a moment to analyze the file.
3 - If any problems were found, it will ask if you want to repair them.
4 - It will then ask if you wish to save a report on the .msh you selected.
-done.


The idea is to reduce the number of edits needed when doing simple hex edits.
The way I see it, everytime you alter a .msh by hand, there is a potential for a mistake to be made.

If you want to, say, change the name of a texture reference.
First you need to make the change, keeping track of the byte size diference caused by your edit.
Then update the size entry for the TX0D.
Then update the size entry for that TX0D's parent MATD.
Then update the size entry for that MATD's parent MATL.
Then update the size entry for that MATL's parent MSH2.
Then update the size entry for that MSH2's parent HEDR.

-or-

Simple change the entry and run it through this program.

I've tested on several files and in a 32 bit environment.  I have no idea what it will do on a 64 bit system, but I have included an x64 version in case it is needed.

The report might be usefull outside of tag size correction, as it lists all the tags in order and the offsets where they are found.  Also, all the offsets should be even. If you notice that any of the offsets are odd, then there is a malformed tag somewhere around the change. This program wont fix that, but the report can help find it

I hope this saves time and makes room for bolder operation on .msh files.

E-mail me or contact me on www.swbfgames.com if you have ANY problems with it.
(include "MSH_TAG_SIZE_VALIDATION_TOOL v1.0" in the topic if you e-mail me.)

Thanks:
SleepKiller for asking about this feature. I hope this helps.
George Lucas for making my second favorite thing, Star Wars.
My wife for being my #1 favorite, and for putting up with late night coding.
Pandemic for making SWBF.
LucasArts, for the Empire of SW I can't get away from.

[SleepKiller]

I love you! I would stay up and test it out, but I have to get up early tomorrow. Thanks for making this.

[tirpider]

I helps me with my other program, so thank you for asking about it.

If it doesn't do what you need, let me know.

[Phobos]

can it fix models that crash in game

I tested the 64bit exe on a bugged mesh found in dmi_prefab_pack assets. dmi_prop_desk it had one bad tag it fixed but I have not tested in game yet.

Code Select Expand


  tag |  tag |  decimal | reported |  Correct |     Size |         
index | name |   offset |     Size |     Size |     diff | repaired
======+======+==========+==========+==========+==========+=========
    1 | HEDR |        0 |   129608 |   129608 |          |         
    2 | MSH2 |        8 |   129600 |   129592 |        8 | repaired


[tirpider]

All it alters is the 4 bytes after the tag. (the size field)
And only if it find a bad size and you give it the ok to fix it.

If the incorrect size fields are causing it to crash, the yes.

The only way to know is to test.



Here is a possibility for failure on the program's part:
If there is a new, un-documented tag in the file, then it will not recognize it and add it to the previous tag.
It will still get saved, but the size of the altered tag before the un-recognized one would be incorrect, and that might hose the munger and or the game (depending on the tag.)

I've accomidated tag names I know about, but havent seen in any msh's, like TX4D and such.
Also for the MYTP mispelling of MTYP.
I was pretty thorough, but it's very possible to miss things.

On a side note, I don't have that asset pack.
You wouldn't happen to have a link, would you?
I'd like to discect that desk

-edit-
NM. Google is my friend. DMI Prefab Pack

-edit again-
The MSH2 on that desk is incorrectly including the CL1L tag at the end of the file.
So the correction is valid.
I still don't know if it will or wont crash a map.

-edit again-
that whole pack seems to have the same issue. (MSH2 + 8 bytes)

-edit again-
Ok tested on a known good model, adding the extra 8 bytes to MSH2 doesn't crash anything, so it must be something else fudging that desk.

-edit AHA!-
This is one of the msh's that has MTYP mispelled as MYTP.
It's at decimal offset 1856 and 1952
Just change to read MTYP
I am willing to bet that if the msh can't tell munge what type of geometry it is, that munge will happily crash it.
(Or at least create a malformed modl chunk somewhere.)

-edit un-AHA-
Ok...
I tried making the error on a known good model (Changed MTYP to MYTP) and it munged and ran perfect.....
...
I'd still correct everything.. the sizes, the MTYP mis-spell.
...
Still looking at it...

[Phobos]

http://www.swbfgamers.com/index.php?action=downloads;sa=view;down=434

[tirpider]

Well, I got it in game with no edits, and no crashes.

the little screenshot is with the size error and the MYTP misspelling.

Have you tried doing a clean or a manual clean before munging?

[Phobos]

That specific model will always crash a mod map, given enough time. Set the server to 16-32 AI and let it run a couple hours and it will crash due to the bugs in that model. I know because I tried for weeks to get it (and other models from the dmi_prefab pack) to work on Phobos and it always crashed. Single player it won't, but multi-player = crash. The solution was to remove the mesh and no crash. I would like to use that desk mesh for a hotel map. If it doesn't crash for your game that is very unusual. I will try to find the dragon head statue mesh, it was really cool but i had to remove it from Phobos due to the crashing. Maybe they can be fixed but I don't know the extent of relevance the mesh tags have on online stability.

Anyway, great job on this new tool. You have made some really nice contributions to the modding community Tirpider and I respect you for that.

PS a clean munge of Phobos takes about 2-3 hours lol

[Led]

Phobos,

What you describe sounds like a memory error or leak to me.  But hey, what do I know


Anyway, have you tried adjusting memory parameter in the addme.lua file?

-- third arg: level memory modifier.  the arg to LuaScript.cpp: DEFAULT_MODEL_MEMORY_PLUS(x)
AddDownloadableContent("MOD1","MOD1c",4)
AddDownloadableContent("MOD1","MOD1a",4)

Code Select Expand



-- add the new tat level to the missionlist
local newEntry = { mapluafile = "MOD1", showstr = "MOD MAP 1", side_c = 1, side_a = 1, dnldable = 1, }

-- append it to the sp missionlist table
local n = getn(sp_missionselect_listbox_contents)   
sp_missionselect_listbox_contents[n+1] = newEntry

-- append it to the mp missionlist table
n = getn(mp_missionselect_listbox_contents)
mp_missionselect_listbox_contents[n+1] = newEntry


-- associate this mission name with the current downloadable content directory
-- you should list all missions in mission.lvl here.
-- first arg: mapluafile from above
-- second arg: mission script name
-- third arg: level memory modifier.  the arg to LuaScript.cpp: DEFAULT_MODEL_MEMORY_PLUS(x)
AddDownloadableContent("MOD1","MOD1c",4)
AddDownloadableContent("MOD1","MOD1a",4)

-- all done
newEntry = nil
n = nil



[Phobos]

bamdur recommended that same trick before but it did not seem to help.

[tirpider]

I only tried multiple copies of the one model without textures.
And only in single player for a few moments on my blank test map.

Since your getting the crashes in multiplayer, thats a starting point... something about multiplayer hates the model.

My guesses on the crashing, is that it has something to do with poly count or complexity.
There is no shadow volume or lowres geometry, so something might be going on there.

Some of the SEGMs are pretty big, poly count wise. But not way too big.

Or some of the tiny detail shapes (the mouse for instance) might be messing with it.
I read somewhere that Zero doesn't like polys to be to small.

Could try yanking out entire SEGM chunks, and see if the problem is localized to a specific geometry.
That could also ruin the model, though.

It could be that simply fixing the size and respelling the MTYP tags might fix it so that it runs right.




BTW, thanks for verifying the x64 functionality.

[SleepKiller]

You've made me so happy right now!    This tool does exactly what I wanted it to perfectly!

[tirpider]

Glad it's working out.

I'm reworking the loader for all my tools with the code from this one.
All the other tool have a built-in error regarding size, and this tool fixes it.
(I wouldn't have made it without your request SK)

I'm thinking a bunch of little tools to do little things to msh files will be easier to make and use than one big tool like I wanted.

Next up for this one is the ability to call it from a command line for use in batch files or called from another program.