Incorrect generation of 0 !LPUB ASSEM FADE_STEP COLOR (0x|#)([AA]RRGGBB)
LDraw™ editor for LEGO® style digital building instructions.
Brought to you by:
trevorsandy
Menu
▾
▴
The line 0 !LPUB ASSEM FADE_STEP COLOR (0x|#)([AA]RRGGBB) is incorrect generated.
Instead of a hex number format (e.g. 00FE8DC0) a name is added:
0 !LPUB FADE_STEP COLOR GLOBAL Aqua
Not sure what the 0x|# for is
Thank you for reporting this behaviour.
By default, LPub3D will use the LDraw safe colour name (name with _ between words e.g. Dark_Brown) becuse HexRGB names may have multiple LDraw colour entries (e.g. Black and Chrome_Black both use #1B2A34).
However, I have updated LPub3D to load fade previous steps colour values with the following formats:
With this change, the editor is no longer limited to LDraw colours, s/he may specify any valid colour.
This change is available in the latest release build.
You can see additional details in the LPub3D GitHub repository at ticket Fade previous steps colour value #689
Cheers,
Yeah, but the problem is that the name will generate an error.
Cheers.
Op wo 22 mrt 2023 om 11:07 schreef Trevor Sandy trevorsandy@users.sourceforge.net:
Can you describe the error and/or steps to reproduce it ?
With the latest release build, I am able to use both LDraw safe name:
And HexRGB colour formats without error.
Cheers,
Last edit: Trevor Sandy 2023-03-23
After checking the line in your example, no quotes are put around it.
I.s.o. "Green" it generates Green. Though I will check first if I really do
have the latest version just to be sure (it was only a couple of weeks ago,
but just in case).
Cheers,
Op do 23 mrt 2023 om 03:41 schreef Trevor Sandy trevorsandy@users.sourceforge.net:
Houston, we have problem. After unpacking (no install any more?) the latest
version LPUB won't even start now.
Cheers,
Op do 23 mrt 2023 om 05:10 schreef Rene Frijhoff rfrijhoff@gmail.com:
Thank you for reporting this behaviour.
Are you using build 2.4.6.98.3209_20230323 ?
I saw that build 2.4.6.96.3207_20230322 failed to download the latest LDraw library archive files during the build process as LDraw.org changed their download URLs. This is why the Windows installer distribution failed to build.
As a result I generated an new build this morning. All builds and build checks were successfully completed.
I downloaded and checked the 2.4.6.98.3209_20230323 x86_64 portable (.zip) build and did not encounter any unusual behaviour.
Cheers,
Last edit: Trevor Sandy 2023-03-23
Unfortunately, also 2.4.6.98.3209_20230323 won't start. I even rebooted the
pc just to be sure.
Cheers
Op do 23 mrt 2023 om 12:16 schreef Trevor Sandy trevorsandy@users.sourceforge.net:
Strange. Im not able to reproduce this behaviour on Windows 10 or 11.
Can you provide your operating system version ?
Is anything being written to the LPub3D output log ?
Can you try to run LPub3D from the command console and direct the output to a log file. Here is the command:
Of course you must replace
<absolute path>with the respective actual file path.If the test_output_log.txt file from the above check is not empty, can you provide a copy - along with the default LPub3D output log ?
The best way to run this test is to use a new extracted instance of a 2.4.6.98 portable (.zip) LPub3D distribution.
Cheers,
Last edit: Trevor Sandy 2023-03-24
It's becoming more strange. There was nothing written to the log file.
When using the command prompt, it didn't start for the 1st 2 times. When
trying for the third time, I made an error in the model path. Now LPUB did
start, but gave an access error because of the typing error in the path.
When corrected, LPUB did start with loading the model file. It now also
starts when clicking the icon.
Cheers.
Op vr 24 mrt 2023 om 15:18 schreef Trevor Sandy trevorsandy@users.sourceforge.net:
Looks like you are experiencing this issue because of the file path being used.
Can you consistently reproduce the unexpected behaviour using the problematic path ?
A good test would also check UTF-8 characters. For example, does your path contain non-ascii characters that might be obfuscating your file path. Using UTF-8 characters in file names should not cause unexpected behaviour but it could be good to rule it out.
Cheers,
It was everytime the same way in the command prompt and never closed
between those attempts. Also this would imply that Windows in the first few
attempts didn't use UTF-8 characters in windows mode and then suddenly
after my attempts it did use UTF-8 characters without me changing anything.
Though I will try later today or tomorrow.
Cheers,
Op vr 24 mrt 2023 om 23:55 schreef Trevor Sandy trevorsandy@users.sourceforge.net:
I deleted the LPub directory and extracted the file again, but the problem
did not arise anymore (well for now) so I can't reproduce it.
Cheers,
Op za 25 mrt 2023 om 06:32 schreef Rene Frijhoff rfrijhoff@users.sourceforge.net:
Ok. I will consider this issue resolved then.
Do not hesitate to let me know if you encounter any other unexpected behaviour.
Cheers,
Will do, thanks!
Op za 25 mrt 2023 om 17:53 schreef Trevor Sandy trevorsandy@users.sourceforge.net: