LDraw.org Discussion Forums

Full Version: [LDPartEditor] 0.8.5 Beta Released
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
There is another dirty workaround

  1. Save your file
  2. Modify it with another program
  3. Open the "old file" in LDPE again and add one space (do not save the modified old file)
  4. Open the context menu for the file in the project tree from the 3D editor and select "Revert All Changes / Reload"
  5. The file is now updated.

As I said, I will improve the file synchronisation with later versions Smile
I had a similar trick, asking for a file save in LDPE, at this moment LDPE realizes that the file was modified externally. Yours seems safer Wink
Quote:As I said, I will improve the file synchronisation with later versions Smile
Thanks in advance Wink
A line (or condline) that has both ends joining a surface that will be selected by a "select ..connected" action will be selected even though it is not adjacent to any element selected. This in not the desired behaviour...
In the above diagram, green line should be considered connected to blue area, but not yellow one.
Rien ne va plus. Version 0.8.6 Beta will include 15 improvements (7 new features and 8 bug fixes).
The release date is 2016-03-20.

[Image: 0.8.6_features.png]
Got a hang-up today... Was working on a moderate size part (21269 hair piece, about 3000 LDraw lines). Hit undo then no answer from LDPE. I finally killed the application, looked at the log file. It appears that it was a heap overflow, see below (I'm on a 4GB memory/32bit XP machine).

Worse: now when I open the file again and try to work on it, LDPE freezes again for a loooong time, then throws this enigmatic message: "Registered 0 new file(s) Deleted 0 file(s) Detected 0 unsaved file(s). They are opened with LDPE but another version (older or newer) is stored on the HD or the original file was deleted from HD". If I press OK and try to work on part again, the same behaviour starts again. I tried to close LDPE and start again, same problem. I even restarted computer, no way!!! Sad
I tried to rename the part file, same problem. Removed header from file, finally was able to edit file again. Phew!

(edit) One might say I'm always ranting, but I must say that LDPE is a very nice tool to adjust shape around minifig head, fit stud primitive or tune lines/condlines (result here http://www.ldraw.org/cgi-bin/ptdetail.cg.../21269.dat). Once the most salient bugs are ironed out it will be a really great tool! Might benefit of some speed optimisations too Wink

log file excerpt:
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.OutOfMemoryError: Java heap space)
    at org.eclipse.swt.SWT.error(Unknown Source)
    at org.eclipse.swt.SWT.error(Unknown Source)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source)
    at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
    at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
    at org.eclipse.jface.window.Window.open(Window.java:801)
    at org.nschmidt.ldparteditor.shells.editor3d.Editor3DWindow.run(Editor3DWindow.java:4920)
    at org.nschmidt.ldparteditor.splash.SplashScreen.run(SplashScreen.java:298)
    at org.nschmidt.ldparteditor.main.LDPartEditor.main(LDPartEditor.java:39)
Caused by: java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOfRange(Unknown Source)
    at java.lang.String.<init>(Unknown Source)
    at org.eclipse.swt.custom.DefaultContent.getTextRange(Unknown Source)
    at org.eclipse.swt.custom.StyledText.getText(Unknown Source)
    at org.nschmidt.ldparteditor.data.DatFile.parseForError(DatFile.java:640)
    at org.nschmidt.ldparteditor.composites.compositetab.CompositeTab$4.modifyText(CompositeTab.java:648)
    at org.eclipse.swt.custom.StyledTextListener.handleEvent(Unknown Source)
    at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
    at org.eclipse.swt.widgets.Display.sendEvent(Unknown Source)
    at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
    at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
    at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
    at org.eclipse.swt.widgets.Widget.notifyListeners(Unknown Source)
    at org.eclipse.swt.custom.StyledText.setText(Unknown Source)
    at org.nschmidt.ldparteditor.data.VM00Base$1$1.run(VM00Base.java:262)
    at org.eclipse.swt.widgets.RunnableLock.run(Unknown Source)
    ... 8 more
Exception in thread "Thread-6" java.lang.OutOfMemoryError: Java heap space
    at java.lang.String.toCharArray(Unknown Source)
    at org.nschmidt.ldparteditor.text.StringHelper.compress(StringHelper.java:82)
    at org.nschmidt.ldparteditor.data.HistoryManager$1.run(HistoryManager.java:110)
    at java.lang.Thread.run(Unknown Source)
I was able to reproduce this "Heap Space" issue with 21269.dat on my WinXP 32bit test system (with 4GB RAM) within five minutes.
The solution is simple: you have to change the command line which is located in the "run.bat" batch file. I have to find out the best settings for the -Xmx and -Xms Java VM command line parameters.
Great! I was nonetheless able to complete the part, but I avoided to use undo, that seems quite ressources hungry...
start "" javaw -Xmx1500m -Xms512m -jar -Djava.library.path="natives/" -jar LDPartEditor.jar
This should be enough to avoid trouble on 32-bit JVMs.
Wishes of the day...
- It's very difficult (except with thickest edge lines, solution that causes other problems) to distinguish between edge lines and mesh lines. I suggest to make mesh lines another color (eg. blue, or better user configurable), and don't show them when they are overlapped by an edge line.
- Speaking of edge line thickness, I am not sure that using some real world line thickness is a good idea: when you zoom in on a tiny area, it becomes covered with fat lines... Fixed pixel sized lines (as used by MLCad and LDView) might be better. Granted, their drawback is almost opposite, unusable pictures when zoomed out too much. But since parts are generally relatively small, I find it tends to work better. Of course the best would be to have the choice between both modes Wink
- what about supporting drag and drop to open a file?
I created some tickets for this feature request. The idea of using drag and drop to open a file is good and easy to implement. This feature will be introduced with release 0.8.7.
Pages: 1 2 3 4 5