| |
In lugnet.cad.dat.models, Tore Eriksson wrote:
> In lugnet.cad.dat.models, Michael Horvath wrote:
> > In lugnet.cad.dat.models, Tore Eriksson wrote:
> > > The new revision of my unofficial Datsville is at:
> > > http://cid-7183b586c107b55b.skydrive.live.com/browse.aspx/.Public/Datsville
> > >
> > > * Fixed minor problems with minifig arms and a misplaced BFC statement
> > > * Updated MovedTo parts with parts from LDraw.org 2011-01 Parts Update
> > >
> > > /Tore
> >
> >
> > 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.
>
> How about a shared Dropbox folder?
>
>
> /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.
I had created a Google Code project for Datsville a few years ago. I will see
about uploading everything there shortly. It's been a while so I'm not 100% sure
I even remember my password correctly.
Mike
|
|
| |
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
|
|
| |
In lugnet.cad.dat.models, Tore Eriksson wrote:
> The only change of layout I disagree to is the moving of the Radio club. Even
> though I agree that it fits in better there, like I said it ruins my special
> plans... So, could you consider moving it back again? :)
Are you sure? It just seems so awkward at that location.
> Interesting - but I believe it conflicts to the files hills.pov, hills.ghf, and
> river.ghf in the POV folder. But maybe we'll find a way to harmonize those two
> approaches?
I think we can safely scrap the old POVray stuff. Though my version is not
necessarily an improvement.
Mike
|
|
| |
I like the two story house model. But, could I make a slight adjustment? For
instance, I don't think it is deep enough.
Mike
|
|
| |
I've uploaded a second revision. It includes several new buildings as well as
some bug fixes.
Mike
|
|
| |
In lugnet.cad.dat.models, Michael Horvath wrote:
> In lugnet.cad.dat.models, Tore Eriksson wrote:
> > Interesting - but I believe it conflicts to the files hills.pov, hills.ghf, and
> > river.ghf in the POV folder. But maybe we'll find a way to harmonize those two
> > approaches?
>
> I think we can safely scrap the old POVray stuff. Though my version is not
> necessarily an improvement.
Really? Yes, I want to scrap them too, but not until we have some better
replacement.
/Tore
|
|
| |
In lugnet.cad.dat.models, Michael Horvath wrote:
> I've uploaded a second revision. It includes several new buildings as well as
> some bug fixes.
>
>
> Mike
Excellent!
I'm still not ready to merge our versions, so I made my own Rev041 (still not
published; too much cleaning to be done first...)
First attempt crashed my PC after 13 seconds of parsing, second attempt with all
unnecessary processes closed down succeeded at almost 11 minutes.
Still missing some vehicles and probably a lot of mistakes made, but here it
is:
http://dl.dropbox.com/u/15954981/_town_1024x768_AA03_10min56sec.jpg
This is getting inspiring again! :D
/Tore
|
|
| |
A third revision is up. The main highlight is that there is now stuff to visit
across the river, as well as two bridges connecting to there!
Also, I added short text descriptions to the file names so you can tell the
models apart.
|
|
| |
In lugnet.cad.dat.models, Michael Horvath wrote:
> A third revision is up. The main highlight is that there is now stuff to visit
> across the river, as well as two bridges connecting to there!
>
> Also, I added short text descriptions to the file names so you can tell the
> models apart.
Could be a good thing to supply the link:
http://code.google.com/p/datsville/
:)
Before I dig into this revision, I only wish to add a few spontaneous comments.
Six railway crossings in such a short distance is a few too much. Two bridges is
enough. I'd say no more bridges. Beyond blocks 22, 13, and 12 I have thought of
quite barren land: Blocky Mountains or stone desert? Maybe farms beyond the
railway, but now I'm open for expansion on the other side of the river instead.
What are your future plans?
/Tore
|
|
| |
I think we have a problem here. I mailed Brickbuilder to ask permission to use
the White Camper Caravan in Datsville and meanwhile put it in the Pending
folder. He never replied, so I guess we have to take that for a 'No'.
/Tore
|
|
| |
In lugnet.cad.dat.models, Tore Eriksson wrote:
> Before I dig into this revision, I only wish to add a few spontaneous comments.
> Six railway crossings in such a short distance is a few too much. Two bridges is
> enough. I'd say no more bridges. Beyond blocks 22, 13, and 12 I have thought of
> quite barren land: Blocky Mountains or stone desert? Maybe farms beyond the
> railway, but now I'm open for expansion on the other side of the river instead.
Noted.
> What are your future plans?
None presently until people start submitting more buildings.
Mike
|
|
| |
In lugnet.cad.dat.models, Tore Eriksson wrote:
> I think we have a problem here. I mailed Brickbuilder to ask permission to use
> the White Camper Caravan in Datsville and meanwhile put it in the Pending
> folder. He never replied, so I guess we have to take that for a 'No'.
>
> /Tore
Too bad. It's a nice model.
Mike
|
|
| |
I've uploaded a seventh revision.
http://code.google.com/p/datsville/
I decided that some of the buildings I made were simply to large, so I made
smaller versions. There's also a new tree model and a radio tower (which needs
to get moved to somewhere better).
I'm no longer able to render the whole town at once in POV-Ray as I have too
little RAM in my computer. I need to come up with an alternate method of
creating town maps. :( Too bad LDView doesn't support orthographic projection;
otherwise I would start using *it* instead.
|
|
| |
Datsville needs some more trees. It has some already but they are very basic. A
greater variety would be good. Anyone want to model some?
|
|
| |
In lugnet.cad.dat.models, Michael Horvath wrote:
> Datsville needs some more trees. It has some already but they are very basic. A
> greater variety would be good. Anyone want to model some?
I really second that request. Steve Bliss's tree is truly brilliant, but now
there are too many of them exactly alike.
/Tore
|
|
| |
Michael Horvath wrote:
> I've been experimenting with Mike Gallagher's SNOT roads and sent him in email
> asking if he would be willing to license them under the Creative Commons or
> Public Domain. Here is how things look right now.
>
> http://i421.photobucket.com/albums/pp292/SharkD2161/LDraw/ldview_screenshot_009.png
That looks nice.
But it is also a challenge to the "home owners". Now I feel I have to
think about how to integrate my houses better with the new streets;
adding paths, driveways with ramps, and other details.
Play well,
Jacob
--
Bregnerod Transit Authority - Moving mini-figs:
http://lego.sparre-andersen.dk/BTA/
|
|
| |
In lugnet.cad.dat.models, Jacob Sparre Andersen wrote:
> That looks nice.
>
> But it is also a challenge to the "home owners". Now I feel I have to
> think about how to integrate my houses better with the new streets;
> adding paths, driveways with ramps, and other details.
>
> Play well,
>
> Jacob
The same author also created a series of examples of driveways and ramps, though
I haven't used any yet.
http://gallaghersart.com/forums/viewreply/77/
Mike H
|
|
| |
I received a reply from Mike G. and he said that we could use his models, and
that he would update all his models with a compatible software license.
You can see in the image below that SNOT roads create a lot more options when it
comes to designing road markings, stripes, and so forth. It's a lot more obvious
now that there are one-way streets in the center of town.
http://i421.photobucket.com/albums/pp292/SharkD2161/LDraw/ldview_screenshot_011.png
Mike H
|
|
|
