You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 18, 2019. It is now read-only.
Affects both current and Next Gen script, though it might be added for Next Gen only.
I became aware of this issue after #75 was reported. That issue reports that LSynth parts are not fully supported, and rightly so. However, there is a larger issue exposed here, as revealed by the cause of the issue.
As it turns out, the LDraw part header is read and dealt with as part of the import process. The error thrown was caused by the Python UTF-8 decoder not properly decoding a character in the part header. However, part headers are not even used in the import process (although it probably should take into account BFC... however that should be done). Therefore, I think it would be best if the header information was discarded before the construction process begins.
This, however, will take some work, as there is no "end of header" META command (though one is being debated [1]), so detecting the header end requires a bit of work [2]). In addition, the original script deals with part of the header in the process (I'm not sure about the Next Gen), so this change is not as straightforward as replacing the open() calls with a call to the header-stripping function. However, I think it should be done, even if it takes a bit of work.
Affects both current and Next Gen script, though it might be added for Next Gen only.
I became aware of this issue after #75 was reported. That issue reports that LSynth parts are not fully supported, and rightly so. However, there is a larger issue exposed here, as revealed by the cause of the issue.
As it turns out, the LDraw part header is read and dealt with as part of the import process. The error thrown was caused by the Python UTF-8 decoder not properly decoding a character in the part header. However, part headers are not even used in the import process (although it probably should take into account BFC... however that should be done). Therefore, I think it would be best if the header information was discarded before the construction process begins.
This, however, will take some work, as there is no "end of header" META command (though one is being debated [1]), so detecting the header end requires a bit of work [2]). In addition, the original script deals with part of the header in the process (I'm not sure about the Next Gen), so this change is not as straightforward as replacing the
open()
calls with a call to the header-stripping function. However, I think it should be done, even if it takes a bit of work.Are there any comments or thoughts on this?
References
1: [LSC Request] End of header meta command
2 End of file header indicator?
The text was updated successfully, but these errors were encountered: