Wednesday, August 18, 2010
Right now the code's definitely not at it's prettiest but it'll slice pretty much any* .stl file, and the MeshMRI will give you a good idea as to why things are going screwy if you're not able to slice a file.
*as long as it's binary and not ASCII
... i have issues with localization - in the GUI i have explicite to replace the "1,00" and "0,00" for scale and rotation with "1.00" and "0.00" or it gives an exception ...
Vik: That's a weird result, two questions: Does it go away if you change the config.txt file, and what's your OS/Java Virtual Machine?
I'll add this to the issues list on the GitHub page.
its on XP and Vista home with Java6 - its the local setings with "," or "." as decimal separator ... the program is expecting "1.00" and the OS changes the "1.0" from config.txt into "1,00" in the GUI.
If i replace the "," in the GUI-screen by "." (really slow, 3 seconds for every interaction on a dualcore) its OK ...
Also, the GUI speed you're getting isn't remotely acceptable-- so far it's run fine on all but pathologically slow systems I've used so far. I'll try to put this thing on some more test systems...
... the OS is not 'converting text', it's converting the representing strings ("1.0" resp. "0.0") from config.txt into a float-value and when displaying in the GUI it's using the local settings, what's "," as decimal separator in Germany ...
I have similar issues with other programs and Excel too, so i have often to convert CSV's prior to importing them in Excel ...
Maybe you can include a check for local settings and then use the specified decimal separator in the parser?
I think the implementation might come in the form of a variable you can set in the config.txt file.
I'm trying not to really spam the Builders blog with bad updates, so the next time I post here will be with this and other upgrades, but if you keep an eye on the github page the fix for this bug should be up comparatively soon (<1 week).
Links to this post: