Post by giftfish on Jan 18, 2017 18:16:39 GMT
@modders -- I, for one, would love if we could communicate with each other a bit regarding the types of output messages from the ME3Logger.
To my knowledge, both Heff's version and Erik JS's version provides debug output, but Heff's at least varies as to how useful it can be to track down problems. The output often isn't very explicit. Also common is the fact that it will provide output, giving the impression that something is wrong, when the game will run fine when tested. This is problematic, as if the game doesn't show a clear problem when tested (crash, freeze, whatever), you are unlikely to even check the output. So, you will be unaware of the potential problem.
I'd like more information on which messages are deal breakers and which are not (obviously if the game freezes or crashes, that's a problem). If we can get folks to put some examples in this thread, that would be great. If we start to get a lot, then I could pop them into a spreadsheet or something.
No problems, totally clean.
Bad export reference.
Object is trying to access an export that does not exist. Crash/Freeze if the object is used, game may run fine if object isn't used (but should still be fixed).
Tips on troubleshooting:
Bad import reference.
Object is trying to access an import that doesn't exist. Crash.
For troubleshooting tips, see "Bad Export Reference". Adjust criteria for imports rather than exports.
Bad "data pointers".
Conflicting information across files. Crash.
Took me a week to track the source of this problem down: a bad index associated with the BIOG_HMM_WI_A package export. The clue in the debug is that they have different names: "BIOG_HMM_WI_A_0" and "BIOG_HMM_WI_A". The one in my modded file had an index of 1. The identical export in a different file loaded simultaneously had an index of 0. The game did not like this. Had there not been another file with the same animation loaded at the same time, I might not have known.
As for *how* the index got changed. This is b/c I cloned the package before cloning it across files. I cloned the package b/c I didn't want to pull the entire tree, as it had about two dozen animations in it. I only needed one. Moral of the story: check your indices. Especially when cloning first in the source file.
Data size error.
Expected data size doesn't match actual data size. Will produce inconsistent results across machines. Normally a hang.
The logger identifies the problem object by name and index number. Therefore, look for an Interp with index #280.
This is very likely the result of an old toolset bug (the object was vanilla, but in a modded file) but it would technically possible to get this error when doing a manual BIN replace. Essentially, you have some extra data in the object. Where and how much extra data like controls how badly the game will react. In this case, there were an extra 4 bytes of zeros at the end of the export. Removing them fixed the error.
To my knowledge, both Heff's version and Erik JS's version provides debug output, but Heff's at least varies as to how useful it can be to track down problems. The output often isn't very explicit. Also common is the fact that it will provide output, giving the impression that something is wrong, when the game will run fine when tested. This is problematic, as if the game doesn't show a clear problem when tested (crash, freeze, whatever), you are unlikely to even check the output. So, you will be unaware of the potential problem.
I'd like more information on which messages are deal breakers and which are not (obviously if the game freezes or crashes, that's a problem). If we can get folks to put some examples in this thread, that would be great. If we start to get a lot, then I could pop them into a spreadsheet or something.
No problems, totally clean.
ME3Log - Logging started.
Shutting down, clean exit.
Bad export reference.
Object is trying to access an export that does not exist. Crash/Freeze if the object is used, game may run fine if object isn't used (but should still be fixed).
Bad export index 5350/2937
Tips on troubleshooting:
- Focus on cloned in exports, first.
- Try using the Export tab in PackEd to locate the bad reference, since all cloned in exports will be at the bottom; Tree View makes it easy to miss exports, as they might spread across several packages.
- Look for Unreal property reference that has an export number that isn't followed by a name, "2877" (MaterialExpressionTextureSampleParameterNormal). This means the export doesn't exist in the modded file and is still referring to the export in the source file you cloned from.
- Don't forget sequence objects. These references like to hide inside output/variable links. Especially with the former, they will not be visible on the sequence map.
- Export references can also be in the binary, when cloning in materials, skeletal/static meshes, and other classes with binary.
Bad import reference.
Object is trying to access an import that doesn't exist. Crash.
Bad import index 392/218
For troubleshooting tips, see "Bad Export Reference". Adjust criteria for imports rather than exports.
Bad "data pointers".
Conflicting information across files. Crash.
BioDynamicAnimSet::MergeInDynamicSet - Cannot merge animsets with different data pointers. Trying to Merge 'BioD_ThnMod_KolyatP2.TheWorld.PersistentLevel.Main_Sequence.SFXSeqAct_SetAmbientPerformance_4.BioDynamicAnimSet_3595' into 'Transient.G_DYN_HMM_WI_StandTyping' with corresponding data pointers 'BIOG_HMM_WI_A_0.HMM_WI_StandTyping_BioAnimSetData' and 'BIOG_HMM_WI_A.HMM_WI_StandTyping_BioAnimSetData
Took me a week to track the source of this problem down: a bad index associated with the BIOG_HMM_WI_A package export. The clue in the debug is that they have different names: "BIOG_HMM_WI_A_0" and "BIOG_HMM_WI_A". The one in my modded file had an index of 1. The identical export in a different file loaded simultaneously had an index of 0. The game did not like this. Had there not been another file with the same animation loaded at the same time, I might not have known.
As for *how* the index got changed. This is b/c I cloned the package before cloning it across files. I cloned the package b/c I didn't want to pull the entire tree, as it had about two dozen animations in it. I only needed one. Moral of the story: check your indices. Especially when cloning first in the source file.
Data size error.
Expected data size doesn't match actual data size. Will produce inconsistent results across machines. Normally a hang.
SeqAct_Interp promar_airlock_m_D.Node_Data_Sequence:SeqAct_Interp_280: Serial size mismatch: Got 2384, Expected 2388
The logger identifies the problem object by name and index number. Therefore, look for an Interp with index #280.
This is very likely the result of an old toolset bug (the object was vanilla, but in a modded file) but it would technically possible to get this error when doing a manual BIN replace. Essentially, you have some extra data in the object. Where and how much extra data like controls how badly the game will react. In this case, there were an extra 4 bytes of zeros at the end of the export. Removing them fixed the error.