Skip to content
This repository has been archived by the owner on May 18, 2019. It is now read-only.

UnicodeDecodeError with LSynth parts #75

Closed
virtualrepublic opened this issue May 16, 2014 · 7 comments · Fixed by #79
Closed

UnicodeDecodeError with LSynth parts #75

virtualrepublic opened this issue May 16, 2014 · 7 comments · Fixed by #79
Labels

Comments

@virtualrepublic
Copy link

I have a model with LSynth parts (flexible hoses) what can't be loaded.

The .dat files are loacted in "LDRAW > Unofficial > LSynth". But I need to copy them into the "parts" folder otherwise they can't be found. LDView and MLCad will load the model without errors.

When I have copied the files into "parts" I will get the following error when loading my test file with a small LSynth model:

//

[LDR Importer] Attempting to import M:\140000_LEGO\MODO\ISSUES\LDR-Importer\UnicodeDecodeError.ldr - 13:16:57.41

[LDR Importer] ERROR: UnicodeDecodeError
Traceback (most recent call last):
File "C:\Users\michael\AppData\Roaming\Blender Foundation\Blender\2.70\scripts\addons\import_ldraw.py", line 781, in create_model
LDrawFile(context, file_name, mat)
File "C:\Users\michael\AppData\Roaming\Blender Foundation\Blender\2.70\scripts\addons\import_ldraw.py", line 165, in init
self.parse(filename)
File "C:\Users\michael\AppData\Roaming\Blender Foundation\Blender\2.70\scripts\addons\import_ldraw.py", line 291, in parse
lines = f_in.readlines()
File "C:\Program Files\Blender Foundation\Blender\2.70\python\lib\codecs.py", line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 92: invalid start byte

  • 13:16:57.43

[LDR Importer] ERROR: Reason: UnicodeDecodeError. - 13:16:57.43

//

Here's the test file with the LSynth parts from the LDRAW installation. You need to copy them into the official "parts" folder:

http://lego.virtualrepublic.org/issues/LDR-Importer/LDR-Importer_UnicodeDecodeError.zip

@virtualrepublic
Copy link
Author

If you can fix this issue please add the LSynth path to your script. Thank you.

@le717 le717 changed the title UnicodeDecodeError UnicodeDecodeError with LSynth models May 16, 2014
@le717
Copy link
Owner

le717 commented May 16, 2014

This is a duplicate of #51.

I added some code in 4e3942f that should have helped improve this, but it seems it didn't. :\

Moving to v1.2 milestone.

@le717 le717 added this to the 1.3 milestone May 16, 2014
@le717
Copy link
Owner

le717 commented May 17, 2014

@virtualrepublic I am going to look into this ASAP and work on getting this fixed. The error being thrown is really odd, as it should not be happening. Ah well, that's what debugging is for. :)

As for the proper location, is ldraw/unofficial/lsynth the traditional installation for them, or is that where you just place them?

@le717
Copy link
Owner

le717 commented May 17, 2014

@virtualrepublic I'm looking at your logs and the example model you sent (BTW, they helped a lot), and I found where the error is stemming from. It's in LS22.dat, line 3. 0 Author: Fredrik Glöckner [fredrigl]. It cannot decode the ö character (odd, since it is opening it in UTF-8 mode). I recall fixing this same error in one of my Python applications, I'll try to remember what it was. This particular error should be fixed in no time.

@MinnieTheMoocher Considering your expertise on the LDraw file paths, perhaps you can impart some of your wisdom here. I've run the LSynth installer, and it wants to install the files at C:\Program Files (x86)\LSynth, but I'm with @virtualrepublic here and would rather have them at ldraw/unofficial/lsynth if possible. What do you recommended being done here?

@virtualrepublic
Copy link
Author

Thanks for the fast reply. The path should be C:\Program Files (x86)\LDraw\Unofficial\LSynth because that's the official path when you install the official LDRAW package.

@le717 le717 changed the title UnicodeDecodeError with LSynth models UnicodeDecodeError with LSynth parts May 18, 2014
le717 pushed a commit that referenced this issue May 18, 2014
I have tested this with the example model @virtualrepublic sent in #75,
and it works as it should (at least, it looks as if it should on my
end).
@le717 le717 closed this as completed in #79 May 19, 2014
@le717 le717 reopened this May 19, 2014
@le717
Copy link
Owner

le717 commented May 19, 2014

Oops, didn't mean to close this.

This was referenced May 19, 2014
@le717 le717 modified the milestones: 1.2.5, 1.2.0 Jul 4, 2014
@le717 le717 mentioned this issue Jul 4, 2014
9 tasks
@le717
Copy link
Owner

le717 commented Jul 4, 2014

Moved to v1.2.5 milestone per reason at #82 (comment).

@le717 le717 removed the duplicate label Aug 8, 2015
@le717 le717 removed this from the 1.3.0 milestone Aug 8, 2015
@le717 le717 closed this as completed Aug 8, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants