|
In lugnet.cad.dat.models, Michael Horvath wrote:
> > > I have some time on hand that I plan to spend on Datsville. Mainly some
> > > organizational things and a few tweaks. I will use your revision as a basis.
> > >
> > > I think it would be cool to solicit submissions from users of LDD as well as
> > > LDraw, for instance from users of the Eurobricks discussion forums. I'll post a
> > > message there once I'm done.
> > >
> > >
> > > Mike
> >
> > That's really great news, Mike! I like all your ideas and I give you quite free
> > hands. And if there isn't anything I absolutely can't accept, I'll include your
> > changes in "my" future unofficial versions of Datsville.
> >
> >
> > /Tore
>
>
> Here is an image of the changes:
>
> http://i421.photobucket.com/albums/pp292/SharkD2161/LDraw/datsville_map_legend.jpg
>
> Here are the changed files:
>
> http://www.mediafire.com/download.php?u2vo5kocc32k2nr
>
>
> I reorganized all the models so that they are labeled consecutively, and appear
> in consecutively numbered blocks (block_001, block_002, etc.). The city streets
> and traffic now also appear in their own "layers". I find this to be a bit more
> manageable. Lastly, I had to move a few buildings in order to extend the
> streets, and I tentatively added two parking garages in case Datsville gets
> bigger. These last two can be removed if need be.
Hmm, I'm aware that I said I'll give you quite free hands, but well...
First, the order of those blocks are a little strange to me:
20,19,18
14,15,16,17
13,4,3,1,2
12,5,6,7,8
9,10,11
(and building #45 does not even belong to any block?)
I can't find any logic behind that numbering, and as Datsville hopefully grows,
it will become even more inconsistent. I've never really liked "town00",
"town-21", but at least there was a clear logic behind that naming.
Second, you have made an (almost) irreversable Boxer simplification, removing as
good as every existing stud. That could have been made in almost every viewer as
well as L3P instead of altering the models.
Third, even if I realise I can't cling to the 8.3 format forever, long filenames
make my MoveTo utility useless. That would probably be no problem, there must be
plenty of better programs available to do the same job. But there has to be
something to gain when you do all the work to rename the models. IMO,
"building_003" tells a lot less than "bjgchur" B for building, JG for Joseph
Gonzalez, and max five more chars for a description. In this case, chur for
Church. I guess it's time to leave the 8.3 boundaries, even though I will miss
the safety within it. But when break free from it, I think it would be a good
idea that the filename of the models includes which parent block it belongs to.
So, for example, if we keep the name Block019, the shopping center will not be
Building_036 but rather Building_019A and the train station Building_019B
instead of Building_037.
Forth, where is the Radio club house behind the Police station? I had great
plans for it to have a central role in a mysterious adventure taking place in
Datsville.
Fifth, there where some files missing
vehicle010.ldr
block_009.ldr
infrastructure_.ldr
m6643.ldr
m6666.ldr
I really like most of the reorganisation of the buildings, they make good sense.
But in all, the renaming is IMHO a step down instead of an improvement. And the
simplification is too heavy an can't be undone (which would have been possible
if I had developed LDSwitch and LDBoxer as I once planned, so I take some
responsability for that...) So, I am very, very sad to say I can't currently
jump off my project and join yours for now being.
/Tore
|
|
|
In lugnet.cad.dat.models, Tore Eriksson wrote:
> Hmm, I'm aware that I said I'll give you quite free hands, but well...
>
> First, the order of those blocks are a little strange to me:
> 20,19,18
> 14,15,16,17
> 13,4,3,1,2
> 12,5,6,7,8
> 9,10,11
That's because there is no order other than first come, first serve. Nor is a
fixed order possible unless you design the town using some algorithm. This is
like a typical database.
> (and building #45 does not even belong to any block?)
Yes, it does belong to a block, #21.
> I can't find any logic behind that numbering, and as Datsville hopefully grows,
> it will become even more inconsistent. I've never really liked "town00",
> "town-21", but at least there was a clear logic behind that naming.
The old system arbitrarily split the town at fixed intervals, cutting through
neighborhoods in the process. This resulted in inconsistencies such as a house
being located in one file and its back yard in another. The new blocks on the
other hand allow you to edit buildings that are adjacent in the same file. They
are also smaller and easier to edit.
> Second, you have made an (almost) irreversable Boxer simplification, removing as
> good as every existing stud. That could have been made in almost every viewer as
> well as L3P instead of altering the models.
Simply use a grep utility to delete all instances of the string "b\". Notepad++
can do this for a directory full of files.
> Third, even if I realise I can't cling to the 8.3 format forever, long filenames
> make my MoveTo utility useless. That would probably be no problem, there must be
> plenty of better programs available to do the same job. But there has to be
> something to gain when you do all the work to rename the models. IMO,
> "building_003" tells a lot less than "bjgchur" B for building, JG for Joseph
> Gonzalez, and max five more chars for a description. In this case, chur for
> Church. I guess it's time to leave the 8.3 boundaries, even though I will miss
The old file names were gibberish to me. What's the point of storing author
information in the file name? Better to store all that stuff in a spreadsheet,
especially if the town grows bigger. You learn in database development that when
you try too hard to name stuff you defeat yourself. Database entries are
typically identified using a single indice: 1, 2, 3, 4, etc. This will become
important later on if we create a HTML/PHP/MySQL virtual tour and town directory
which I am planning.
> the safety within it. But when break free from it, I think it would be a good
> idea that the filename of the models includes which parent block it belongs to.
> So, for example, if we keep the name Block019, the shopping center will not be
> Building_036 but rather Building_019A and the train station Building_019B
> instead of Building_037.
If you do this then you have to rename all the files when you move a building.
Much easier to simply refer to the chart I made.
> Forth, where is the Radio club house behind the Police station? I had great
> plans for it to have a central role in a mysterious adventure taking place in
> Datsville.
It has moved to the northeast, closer to the town center.
> Fifth, there where some files missing
> vehicle010.ldr
> block_009.ldr
> infrastructure_.ldr
> m6643.ldr
> m6666.ldr
I have a hard time figuring out when this occurs because MLCAD is constantly
complaining about missing sub models in MPD files. So I can't tell a real
problem from a false positive.
> I really like most of the reorganisation of the buildings, they make good sense.
> But in all, the renaming is IMHO a step down instead of an improvement. And the
> simplification is too heavy an can't be undone (which would have been possible
> if I had developed LDSwitch and LDBoxer as I once planned, so I take some
> responsability for that...) So, I am very, very sad to say I can't currently
> jump off my project and join yours for now being.
>
> /Tore
|
|
|