Update on some modding issues

**Bethencourt** · September 27, 2013, 11:45 AM

I have left the vanilla name to a mod pack table that only changed vanilla values and it works perfectly. It is not working when I change the name of the table, no matter if it is movie or mod pack type.

I have been testing this with files updates from last Friday untill yesterday. I have not modded with previous updates of the files, so I do not know if they are affected by this.

**alhoon** · September 28, 2013, 12:41 PM

So...
what we do to put our mods back? Where are those 5s that have to be changed to 3s etc?

**alhoon** · September 28, 2013, 05:34 PM

Anyone please?

**daniu** · September 28, 2013, 05:39 PM

Oh, I missed that detail up to now:

As I think has been described elsewhere, the lower three bits of the precedence byte are a simple ordering sequence

What are the other 5 bits? I thought the whole byte was determining load order.

@alhoon download the tool I link to in my first response in this thread, you can use it to set the byte to 5 as Guy says we should.

**alhoon** · September 28, 2013, 06:34 PM

Thanks!
Unfortunately, Can't rep you yet for this awesome solution.

**husserlTW** · September 29, 2013, 05:31 PM

I think CA (or/and Sega) should let the stuff do their job without the stress for a quick release.

**daniu** · September 30, 2013, 02:10 AM

Another thing I just realized:

Originally Posted by Jack Lusted

I am getting the precedence order checking the wrong way around. [...] However, until the patch drops you can change this value to 5. Once the patch drops I can’t guarantee that your mods will work if you don’t switch the byte back to 3 (this has always been the case with mod packs).

How is changing the value from 3 to 5 going to help anyway?
If the problem is that the files get loaded in the wrong order, so Mods (3) aren't overwriting Release/Patch (1/2), how will they do so with 5?

**Jack Lusted** · September 30, 2013, 02:33 AM

Originally Posted by daniu

Another thing I just realized:

How is changing the value from 3 to 5 going to help anyway?
If the problem is that the files get loaded in the wrong order, so Mods (3) aren't overwriting Release/Patch (1/2), how will they do so with 5?

Because 5 will be loaded last, even after movie type packs.

**daniu** · September 30, 2013, 02:57 AM

Originally Posted by Jack Lusted

Because 5 will be loaded last, even after movie type packs.

But both 3 and 5 should be loaded after 1 and 2, so if the order is wrong, they both will be loaded earlier... or is it the third bit that makes the difference?

**Jack Lusted** · September 30, 2013, 03:16 AM

Originally Posted by daniu

But both 3 and 5 should be loaded after 1 and 2, so if the order is wrong, they both will be loaded earlier... or is it the third bit that makes the difference?

It's mod packs that are being loaded in the wrong order, not any others.

**crzyrndm** · September 30, 2013, 03:18 AM

Originally Posted by daniu

But both 3 and 5 should be loaded after 1 and 2, so if the order is wrong, they both will be loaded earlier... or is it the third bit that makes the difference?

It almost sounds like a bit mask had a typo (0101 instead of 0011).

**daniu** · September 30, 2013, 03:23 AM

I'd also really like to know what do the other 5 bits do. It's kind of a revelation to me that only the lower three bits determine load precedence.
From the values in the Shogun packs I can guess 10xxx is a music bit: there were sound.pack and music.packs with 10001 and 10010, respectively. But also 10111 (sound) and 11000 (music)... confusion on my part.
Then, there are a boot and shader packs with 1000xxx set (1000000 for boot, 1000001 and 1000010 for shaders). I don't have the packs available right now, but the 0x40 boot pack may also have contained shader code...

I'm guessing mods should generally stay away from the upper bits which I guess is fine as long as the others are not required to be set to mod shaders or music or something.