| |
In lugnet.cad, I had written:
> > Agreed. Sorry I didn't test it better. We fixed one issue, but not both.
> >
> > http://alumni.cse.ucsc.edu/~dulcaoin/LEGO/FoundryC.zip
Now
http://alumni.cse.ucsc.edu/~dulcaoin/LEGO/FoundryD.zip
is the version to use.
Philippe Hurbain wrote:
> Thanks, works great now!
>
> Two new bug reports nonetheless ;o)
> - Line number shown in status bar is off by one (eg it shows 234 when actual
> line in the file is 235)
This had been purposeful, base-0; I convinced that the status bar should start
at 1. %d should now represent base-1 line number in the command line issued,
and %D represents the base-0 line number.
> - Both display and tree expansion use Hi-res primitives (when they are
> available) instead of regular ones, even when 48\ is not specified. While this
> can be considered as a feature, this behaviour is annoying for parts authors.
Yes, this was done on purpose. But because PHILO WANTS IT (kidding), we added a
menu choice to determine whether to use high-res primitives or not. Your current
choice is cached in the registry so it will be remembered between runs of the
application.
-- joshua
|
|
| |
> This had been purposeful, base-0; I convinced that the status bar should start
> at 1. %d should now represent base-1 line number in the command line issued,
> and %D represents the base-0 line number.
Thanks - text editors I know start numbering at 1.
> > - Both display and tree expansion use Hi-res primitives (when they are
> > available) instead of regular ones, even when 48\ is not specified. While this
> > can be considered as a feature, this behaviour is annoying for parts authors.
>
> Yes, this was done on purpose. But because PHILO WANTS IT (kidding), we added a
> menu choice to determine whether to use high-res primitives or not.
;o)
In a perfect world Hires would be a good choice, but since everything is not
hires substitution yields misfits and gaps I find especially ugly (same thing in
LDview).
I have another little complaint: I find it too easy to inadvertently edit and
modify LDraw primitives. Could it be possible to handle files placed in LDraw
folder differently and issue warning if the user tries to modify them?
Philo
|
|
| |
> > This had been purposeful, base-0; I convinced that the status bar should start
> > at 1. %d should now represent base-1 line number in the command line issued,
> > and %D represents the base-0 line number.
>
> Thanks - text editors I know start numbering at 1.
That's why the easier one to use, lower-case, is 1; and the backup option is
there "just in case".
> > > - Both display and tree expansion use Hi-res primitives (when they are
> > > available) instead of regular ones, even when 48\ is not specified. While this
> > > can be considered as a feature, this behaviour is annoying for parts authors.
> >
> > Yes, this was done on purpose. But because PHILO WANTS IT (kidding), we added a
> > menu choice to determine whether to use high-res primitives or not.
>
> ;o)
>
> In a perfect world Hires would be a good choice, but since everything is not
> hires substitution yields misfits and gaps I find especially ugly (same thing in
> LDview).
Oh, we agree, and that's why it's now an option. The original intent was to get
the best looking viewer for developing the OBI syntax (shhh!), so we went for
what looked best.
There has been some test work done to show the 'Cool Silver Diffuse' parts
(black with a "spray-painted silver" overcoat look to them, from 2005 onward)
with the right speckles that's very promising, for instance. Well, promising,
anyway; not sure about "very" promising.
> I have another little complaint: I find it too easy to inadvertently edit and
> modify LDraw primitives. Could it be possible to handle files placed in LDraw
> folder differently and issue warning if the user tries to modify them?
OK, so I think we're now getting to user-feature requests, over things that need
serious attention. Which is fine, but for a technology preview, it's probably
best not to focus on the small details before there are major features
implemented that need attention first.
That said, let me understand better... do you want a warning issued whenever the
user tries to [Edit] or change the winding of any portion of a part file
appearing the in the p/ directory?
This sounds like an important consideration for long-range plans as Foundry
starts to truly allow editing of bricks.
For now I'd say that the target user of this Tech Preview should probably know
exactly what he's (or she's) doing, despite the nice trappings of a win32 file
dialog and so forth; and not fall victim to thinking that the app is in any way
feature complete or well tested yet.
Please go at this app carefully with test data and look for cracks in the armor.
If we can't find those, then hopefully we'll get some better features
implemented (adding lines is in development right now), and THEN start fixing
any user-features we forgot to design in.
Just the same, presuming I understood your intent, that design feature is
strongly noted.
-- joshua
|
|
| |
> There has been some test work done to show the 'Cool Silver Diffuse' parts
> (black with a "spray-painted silver" overcoat look to them, from 2005 onward)
> with the right speckles that's very promising, for instance. Well, promising,
> anyway; not sure about "very" promising.
(drooling over the possibilities...)
> > I have another little complaint: I find it too easy to inadvertently edit and
> > modify LDraw primitives. Could it be possible to handle files placed in LDraw
> > folder differently and issue warning if the user tries to modify them?
>
> OK, so I think we're now getting to user-feature requests, over things that need
> serious attention. Which is fine, but for a technology preview, it's probably
> best not to focus on the small details before there are major features
> implemented that need attention first.
Sorry again... I totally agree that it is something that can wait for an
official release!
> That said, let me understand better... do you want a warning issued whenever the
> user tries to [Edit] or change the winding of any portion of a part file
> appearing the in the p/ directory?
Yes - parts/ too.
> Please go at this app carefully with test data and look for cracks in the armor.
> If we can't find those, then hopefully we'll get some better features
> implemented (adding lines is in development right now), and THEN start fixing
> any user-features we forgot to design in.
Sure. Keep us posted with new previews!
> Just the same, presuming I understood your intent, that design feature is
> strongly noted.
Thanks!
Philo
>
> -- joshua
|
|
|
