Battlezone Forums

Whenever I attempt to join my own game using SF I get booted for bad assets. It works fine in previous patches, such as 6.3d, so something changed between patches that screwed it up. I have also noticed this happening with other mods, although mods like GGSE work fine. Any idea of what to do?

Are u using 6.4n?

Currently, yes. I have used earlier patches, but they all had the same result. I don't know the exact patch when this issue started though.

There have been issues in the past with 'recursive' upgrades (e.g. building A upgrading into building B which can upgrade back into building A, like with the Hadean Xenomator/Mega Xeno) causing bad asset issues between players who have the same assets, but these are fixed as of 6.4n. Don't know what could be causing the issues with SFMod, maybe some non-standard upgrading or tapping mechanism. The asset checker has gotten a little more aggressive.

SF Mod hasn't been looked at for a while now I believe. I know it hasn't been modified to use the new recycler variant text file or whatever it was called.

After hours of combing through SF's files to see what might be the problem, I narrowed it down to GSEEKER.odf. I removed it and it works fine now.

[WeaponClass]
classLabel = "dispenser"
wpnName = "Seeker"
fireSound = "mmine01.wav"
wpnReticle = "gseek"
wpnCategory = "SPEC"

[DispenserClass]
shotDelay = 1.3
objectClass = "seeker"


That is all that was inside GSEEKER, so I don't know how that could cause bad assets.

gseeker.odf in SF has this:

objectClass = "seeker"

but seeker.odf has classLabel = "seeker"

which is why gseeker.odf in patch 1.3 now points to seeker1.odf

Side note, in the past, the ODF name "seeker1.odf" *could* have been an issue, however now engine generated ODFs (that would append numbers) add a an extra character that is illegal in the windows files system.

This would not actually affect the seeker because the engine doesn't make its generated ODFs in that case, but just a warning if you try to do this with lets say, a unit odf, in an older version of bz2.

Vadam-
Try loading your map in the latest (1.3.6.4n) version of bz2edit.exe. Look at the in-game console after loading a map, and/or battlezone.log. If it notes any errors, fix them. Repeat.

1.0-1.2 allowed weapons and ordnance with the same class. That's forbidden in latest. Needs a little tweaking, but we put in plenty of messages alerting users to that.

-- GSH

I have been doing that, although the only errors I noticed were weapons pointing to effects that did not exist. I stopped using the in-game console after this happened



Figured it was much easier to go into the log file, hit CTRL F, and just type in "error"

you can get rid of those msh messages by copying the newly-created .msh files to your recursed mod folder.

Follow the instructions that are printed for you onscreen, and the messages go away. And, your load times will get better as it doesn't have to reconvert xsi -> msh every run.

-- GSH

GSH wrote:Follow the instructions that are printed for you onscreen, and the messages go away. And, your load times will get better as it doesn't have to reconvert xsi -> msh every run.

-- GSH

Also, there is a low chance MSHs will generate differently between computers, or just 2 successive tries on the same computer. Another good reason to be sure everyone has the same MSHs to avoid Bad Assets.

I think .msh files are asset-checked -- if the size of a craft is different, then its physics parameters would be different, and resync time. Thus, it should get bad assets if they vary.

I also think that the xsi -> msh converter is more stable now that I've taken a pass at ensuring that all intermediate buffers are cleared to consistent values before use. But, I'm not going to burn time trying to dig down inconsistencies from run to run or computer to computer.

-- GSH

Best just be better safe than sorry.

MSH is most certainly asset checked.