BAT4MAX - Issue with .fsh integration to SC4MODEL

[Girafe 1,729]

Hi,

I could not find the topic regarding problems from BAT4MAX so I opened this one.

I am facing issues while exporting with BAT4MAX under 3dsmax 2012. It seems it is connected to Windows, potentially UAC. I deactivate it from WIndows 7 without positive changes then I moved to Windows 10 but same problem.

The .fsh are not integrated properly to the SC4MODEL generated by Gmax and I suppose that Windows is blocking the process.

This is what I obtain opening the SC4Model with reader. Anyone managed to solve this problem?

Note: I am running Gmax and 3dsmax as Administrator.

Thank you in advance.

[rsc204 21,808]

On 20/07/2020 at 3:31 PM, Girafe said:

The .fsh are not integrated properly to the SC4MODEL generated by Gmax and I suppose that Windows is blocking the process.

I think there's a good chance Windows is blocking fshwrite.exe or DatCmd.exe, both command line programs that are part of the BAT4Max export process. The first converts the BMPs from 3DS Max to SC4's FSH format, whilst the later simply packs the new FSH files into the SC4Model file.

Usually running the application as Admin, along with disabling of UAC is sufficient to avoid permissions issues, although the big change from Windows 7 is greater security within Program Files and certain system folders in general, designed to protect you against Ransomware.

Take a look at the information in this thread, it explains what "Controlled Folder Access" is, hopefully it will help you to determine if 3DS Max has full access or not to write files in the install folder.

I went through the process of installing 3DS Max 2011 64-bit with the latest BAT4Max onto a Windows 10 Pro 1903 system last night. However with Admin rights and UAC disabled completely, I had no troubles exporting models/textures using BAT4Max. Since it's BAT4Max that handles this process, the fact I'm using a different version of 3DS Max isn't an issue.

It is also possible to run these scripts manually and end up with the same result, but that's really only a temporary work-around.

It would probably help to know just how far the Exporting Process got before it failed. Inside the following folder Program Files\Autodesk\3ds Max 2011\gamepacks\BAT, there are three things that together will make that clear:

1. What, if anything is in the temp Folder.
2. Does a .BAT (Windows Batch File) exist with the .SC4Model Name, for example "RTMT_PhoneBoothHD_BT_KX-100-0x5AD0E817-0x622E3148-0x00030000"?
3. Inside the Outputfiles folder, is there a corresponding folder with the .SC4Model name (identical to the .BAT file name)?
   Inside that folder should then be (for a successful render):
   1. A subfolder for each individual texture, inside of which would be the actual .BMPs rendered in 3DS Max.
   2. A Set of fsh & fsh.TGI files.
   3. Another Windows .BAT file.

Once we know what parts of the export worked, hopefully we can hone in on the cause.

[Girafe 1,729]

Thanks a lot for your help

Temp folder is empty, in my output folder I have sub-folders with the name of my export and they include subfolder with individual texture, a set of fsh.TGI files and indeed another windows file.

[rsc204 21,808]

So it looks like the FSHWrite process has worked fine, it's getting stuck packing those new FSH files into a DAT.

The first thing to try, is running the Windows Script (.BAT) manually, just double click the last file in your 2nd screenshot. For this to work, you must have the correctly named .SC4Model file located in the root of Plugins, i.e. just as it would be when running the BAT4Max scripts. If that fails, could you send me a complete copy of the folder of the second screenshot for analysis?

The good news at least, we have everything ready as FSH files, we could import them into Reader using other methods if we had too. All of them would be rather more involved though, so I'm really hoping outside of 3DS Max these scripts run without problem. I certainly didn't have to do anything special under Windows 10 myself and it's really a bare-bones install with little more than the OS and some SC4 tools.

[Girafe 1,729]

Thanks again

By running manually the windows script, it inserts the .fsh to the sc4model. What is painful is to delete manually the .ui files coming from the failed automatic insertion process from BAT4MAX. But seems to be the only option I have now. Something taking longer time and feasible for few models.

Will keep on trying and update the topic with results

[Barroco Hispano 26,695]

Have you already installed Autodesk 3ds Max 2012 SP2?

https://knowledge.autodesk.com/support/3ds-max/downloads/caas/downloads/content/autodesk-3ds-max-2012-service-pack-2.html

[rsc204 21,808]

On 26/07/2020 at 6:23 PM, Girafe said:

What is painful is to delete manually the .ui files coming from the failed automatic insertion process from BAT4MAX.

For now you can workaround this by making a copy of the .SC4Model file in Plugins after exporting the LODs with SC4BAT. When, after the 3DS Max export completes, move the original .SC4Model back overwritting the messed up version. Now when you run the .bat script, you should be left with a working file without anything superfluous. 

It's strange though that all parts are being run successfully, except for this weird behaviour which I'd like to say comes from BAT4Max. However, that the .bat script created as part of the export process, works stand-alone, means there is nothing wrong with it. That leaves me trying to understand why things are happening differently specifically when it's done through 3DS Max. But it seems to me something is interfering in that process, potentially corrupting the FSH import, such as they loose the IDs and are seen as UI files instead.

But before we start digging deeper into all this, we should establish that the workaround I mention here actually works. Assuming it does, just for the sake of random/weirdness, I'd re-install BAT4Max again, just to rule out anything having gone wrong. I'm sure it didn't, but given the next troubleshooting steps, we want to be 3000% sure of the little things, before getting into more complex ones.