Free-Mo modules for Trainz?

[StorkNest]

http://www.free-mo.org/
So with discussion on modules in another topic, I got to wondering if this is something worth pursuing. Looks like less standards than N-Trak or U-Make. Just center track to be connected at the end of a baseboard and try to make a prototype scene, might be other things need doing, still reading things here and there. An article I read said this started in Europe and carried over to North America. With TS2009 slowly getting support and TS2010 coming, thought there might be a possibility of starting up some module idea again.

Another variant could be putting iPortals at connection points. I read here you could place iPortals on a route and connect them to each other, so for example you could take 2 modules and connect them with a blank baseboard then delete the blank having a route with 2 seperate modules that connect through iPortals. Here's a simple version.

AB
b
CD

Each capital letter is a scenicked board with an iPortal and the lower case b is a blank. You delete b then you could connect the iPortal at A to C or D and the opposite for B.

Using this method, you could focus on scenes for operation without doing the space in between unless you want to. You could even have scenes normally seperated by distance without worrying about the distance between them. For example if you want to do New York City to Albany, you do 2 modules with scenes from each with nothing between them and just connect the iPortals. Would also be good for long-distance hauls like pooled SP/B&O or NYC/RI and such.

You wouldn't need to use the same track on all boards or the same ballast.

If interesting enough, I'm thinking of writing up standards for it. For now it would consist of:

NOW CALLED VIRT-MO FOR VIRTUAL MODULE

1 - Any module not following these rules will result in a strong request that it be pulled off {insert hosting location}. Sorry but the few standards here need to be enforced so there is less confusion.

2 - All modules must have VM# in front of the name where # shows what Trainz it is for (U=UTC, 4=TRS2004, 6=TRS2006, C#=Classics 1, 2 or 3, 9=TS2009, 10=TS2010). If using an addon, extra letters after the # show what addon is needed (T=Treez, S=Settle & Carlisle, C=Cabon City, M=Murchison).
Examples:
VM4 = Free-Mo TRS2004
VM9MT = Free-Mo TS2009 with Muchison and Treez

3 - A ReadMe file of some sort (at least TXT file) must be included listing content and where to get it. Use -showkuid line in TrainzOptions.TXT to check your module in Surveyor, anything with a White KUID is on DLS, a Red KUID is somewhere else and have the site location listed or unused.

4 - Description of the module must be listed either in config file or ReadMe file including track type (standard, narrow, broad, electric, etc.), # of baseboards to assist users in finding modules of interest and where on the compass to find module joioning locations. If the ends to be joined have a different height than 0 this also must be listed here.
Debating

5 - Ends of baseboards to be joined to another module should be level at the height set to thus avoiding goofy terrain appearance. Tracks at these locations should be 2 grid quares from the end and centered between the baseboard corners (36 grid squares from a corner). If the track ending is more than a single line, center and list in the description if it is double track, triple, etc.

Thoughts?

 

[JCitron]

This is a great idea, and is similar to what we were working on in the old forums. Do you remember the U-Make modules? Your idea is similar, but more refined.

John

 

[StorkNest]

I remember U-Make, I think some later modules drifted away from the rules. This was based on what seems the current popular module method, more flexible, less restricting. I think there is a theme where you try to make the module close to a prototype scene.

 

[mjolnir]

I like the idea a lot, but I'd suggest a different name, maybe "digi-mo", simply on the hope that both our concept and "Free-MO" would become wildly popular, and we'd want to avoid any confusion between the two.

Second, the standards of FreeMo are in part a reflection of certain physical realities that we would not necessarily need to reflect. For example, the minimum and maximum heights of the modules reflect comfortable operating postures for the participants. I have a universal operating height (the height of my computer stool, 29") which works equally well whether I'm working with a route at sea level, or at the 3000 meters. So, do we need standards, as much as we need a registry to publish the information that would let people assess how easy two modules can be interfaced.

Third, even though I like Auran, I'm wary about depending upon them. If we adopt and want to enforce some type of standard naming convention, are we certain that Auran will always require removal from the DLS of a module violating the naming conventions which might be established? Further, Auran has removed the totality of at least one creator's content from DLS. I did not see the offending material, and am willing to accept that the removal was justified. But what if this happens in the future, and the content removed includes a module which does not contain offensive material upon which other depends? Suppose I have do not consider material offensive to which the powers that be object? Because there are answers to these questions I don't much like, I suggest using an independent site (which if were to prove necessary or feasible that a new one be established for the purpose, I would be prepared to help establish, fund, and adminsiter) for the purposes of these modules.

But does a module necessarily have to be hosted for download? Could we accomplish the same by establishing a module (or route) registry? Instead of specifying in detail how the interface between two segments must be constructed, very much needed if you're trying to be sure that all ends can be joined uniformly, maybe all that is really needed is a mechanism for registering modules or routes. A person interested making a module available for use by others registers the module and in doing so, provides the necessary data that enables another person to know whether two routes can be connected (some can't, since unlike Free-Mo, which makes provision for it, routes in TRS cannot be rotated 180 degrees), and how much work is required to do so.

But it occurs to me that the FreeMo is very much a collaborative route of undefined size, and that might be an interesting community project in and of itself.

ns

 

[Johnk]

This is a concept a model railway club used for its travelling layout. Not knowing what space would be allocated at an exhibition, or what shape that space would be, they devised modules that could be placed in a variety of ways. Model Railroader kicked the idea around a lot in the olden days and it's a concept with heaps of merit. It's certainly one I'd enjoy getting involved in because I prefer to play with dioramas rather than building entire layouts.

The first comment I'd like to make is that this concept, or project if you like, dosen't have to involve Auran in any way or form. It could easily be taken to a dedicated site with a dedicated download area and a forum for those who wish to participate in the project. I see absolutely no reason why that site couldn't have its own member's only DLS or repository of all assets used in the project. That way, any member could freely download the assets they need to assemble the module(s) at home. If you did decide to go down that path, I would be willing to offer my web programming experience, supply the bandwidth and a membership site with forum as my contribution. I also wouldn't care if you decided to go elsewhere.

Keep in mind that other than the slow DLS (unless you pay for it) and this forum, Auran doesn't contribute in any way to the establishment of Trainz communities like this. Thus you are free to go where you like without feeling guilty. All you would need, is the authority of the asset owner to store it on an alternative site. I'm not sure how hard that would be, but there are other ways.

This concept is also what I had in mind for a competition next year if there is to be one. It's much easier to get people to build and submit a 2 or 3 baseboard end to end diorama or route rather than a 10 or 20 baseboard labour of love.

Creating rules would be easy enough. One idea would be to use the original u-make module rules (but modified to avoid errors), so that the u-make modules aren't wasted. I think I suggested in another post that the last two grid rows should be flat and textured with a specific colour so that individual sections blend in Each module could have its own little branch line or siding to make life interesting. I guess you'd need different era's and different countries, standard and narrow gauge sections to make it fair on people with different interests.

I noticed in the Free-Mo rules, that modules could be of any length. I'm not so sure that's a good idea in a virtual world however. You will get some character coming along with a 100 baseboard module claiming that it's within the rules. I'd like to see that (say) long modules must be able to be broken up into 2 or 3 baseboards that can be moved around like dominoes.

 

[mjolnir]

I'd prefer that the idea not involve Auran in any material way (As maker of the platform, some of the built-in content, and of Treez, they're obviously involved in a tangential way.) But I don't know that I've seen the U-Make modules, and the forums on which they were developed crashed before I became active in the community, so someone would need to re-post them.

I'm not sure that I see any inherent problem with a 100 baseboard module. In fact, I think that a good overall scheme would have a number of small, operationally intense locations separated each other from by operationally sparse ones of some length. There are doubtless members of the some members of the Trainz community who like the idea of taking an inbound train, switching all of the cars in it to where they need to go, and taking all the outbounds and switching them into a train to depart, while others would be more interested in taking the train from the yard, and running it across 100 baseboards to the next terminal.

As to having two grid rows flat, this pretty much limits the route that can be created to a relatively flat one, or certainly makes a route such as the one pictured here

.

considerably more of a challenge.

ns

 

[MaxMoire]

There is still one active link from eso : http://premium.uploadit.org/esoeso/umakeguide.doc.

And a link to numerous U-Make boards http://trainz.50megs.com/custom.html

And the download station where U-Make is part of.

Cheers
Max

 

[Johnk]

Hi mjolnir. It's a nice photo, but it's not what I'd expect to see in a module designed to blend in with others. That would be a major project, one where a dozen people sat down and planned to build a specific route. Also, 100 baseboards isn't a module, it's also an entire route and a big one at that. How else can you possibly link modules if there isn't a no-man's land between the two? In the following photo, despite both modules being unfinished, the upper one has a small green belt at the end. If the other module had a similar green belt, the two would merge nicely, even if the other module was a rain forest.

 

[mjolnir]

I can see the point, if we're discussing assembling tangible modules into some type of operable layout, that spatial considerations impose the need to have some control over layout for imposing a specific size to a a module. I'm nor persuaded this is the case with digital modules, where physical size is not as much of a consideration.

May I suggest that modules can be categorized into one of two types: links and nodes. A link is a rather long module, in which the primary activity is moving trains, and in which switching (shunting) activities are of less importance. There might be the occasional business, passenger station, and passing sidings (loops) where one train may wait to meet, or be overtaken by another, but on the whole the activity on the link modules is small, relative to the distance. By contrast, A node module is smaller, and has more concentrated activity, whether in a terminal railyard, or a concentration of businesses. Now, I expect that some members of the community will be more interested in switching cars in and out of industries, and will be quite happy to allow the links to be represented by iportals; however, other members will be less interested in switching, and more interested in running through freight or passenger trains, and will be less interested in node modules than in the opportunities presented by link modules. It is therefore necessary, in my view, to have ample quantities of both types.

And I would argue that a hundred baseboard route is not all that long, even if they are laid in a straight line end to end, one board wide. In the Imperial system, the distance represented by 100 boards is about 40 miles, and in North America, while this is a little long between nodes, it is not all that uncommon. And if the route averages 2 boards wide, the distance is only 20 miles, which is a very common distance between "nodes" in the real world.

ns

 

[Dap]

I agree with mjolnir. We need to be thinking outside the box of modular N scale layouts. And the routes we construct from these modules will not
have to be taken down and moved.

Some like to make detailed landscape scenery and if you wanted to make a 100 square long module with awesome scenery, I'd love to have it on my route. That doesn't mean I can't modify it for my own use - say add a branch line diverging at milepost 26 . . .

And they all don't need to be an exact fix. Most of us are capable of placing a square or two between modules to adapt them.

For me, some important statistics that are needed to select an appropriate module would be:
Is it a link or a node?
Size?
Location and elevation of connecting tracks?(north, south east west)
If it is a link, what type of landscape? mountian, desert, farmland, forest, etc.
If it is a node, what does it contain? Industries, yard, passenger station, etc.

 

[Johnk]

I hear where you're coming from mjolnir, so I guess we're talking about two completely different things. I saw the modules as a domino set system where small modules could be built quickly or built as projects by busy people like myself who don't have time for anything larger. These modules could then be moved about at the whim of the user.

Your idea is far more sophisticated and I assume, more long term. Not knowing the answer myself, I thought it could take years to develop a 100 baseboard route, especially like the one in your photo.

If you want to see such large modules built, surely any routes already on the DLS can be married together with maybe one baseboard between each one for the joins. It seems to me that what you're after, is a way of linking routes with a common theme with a common "coupler". I'm not opposed to that idea at all, and the effort would be minimal for all route builders to implement.. All the route builder would have to do is a have track at each end of the route running off the edge at baseboard level.

You seem to have a passion for some kind of module system to be produced, so why don't you take it up and run with it. The more you push it, the more successful it will be. May I suggest that you stir up an interest in these forums, then take the concept to a web site. By all means keep the forum thread alive, but encourage people to visit your site where the rules and screenshots can be seen. My Directory and the Web Ring will help you promote the site, but I could also give you space in the directory for the site itself. That way you wouldn't have to maintain the site. If you sent me the updated copy and photos, I could put them online for you. Alternatively, you could use Webs.com, but that would require extra effort on your part.

John

 

[Dermmy]

The more I read, the better I like this idea.....

I don't think there need be any size restraint, it is necessary in 'real' model railway modules to enable perfect rectangular layouts to be built, but 'virtual' modules don't face the same constraint - the final shape of an assembled layout is largely meaningless, and indeed could (and probably will) be different for every participant and user.

The only necessary constraints I can see is a defined height for ends of modules, and a defined location for tracks at boundaries. A third might be a defined ground texture set.

I also endorse John's comments re moving the idea to a website - somebody was offering free sub-domains for Trainz-related applications not so long ago.

I think I could get into this...

Andy

 

[Johnk]

Snippet: somebody was offering free sub-domains for Trainz-related applications not so long ago.

G'day Andy.Unless I'm mistaken, that was me. I closed the hosting service down after getting absolutely zilch interest (minus one poor soul). I absolutely exhausted myself and probably made myself unpopular with the moderators trying to generate interest, especially with the (then) forthcoming closure of Geocities but, 'Such is life!"

John

 

[mjolnir]

I hear where you're coming from mjolnir, so I guess we're talking about two completely different things. I saw the modules as a domino set system where small modules could be built quickly or built as projects by busy people like myself who don't have time for anything larger. These modules could then be moved about at the whim of the user.

Funny you should mention dominos, as that is also an analogue I've been using privately in my consideration.

Your idea is far more sophisticated and I assume, more long term. Not knowing the answer myself, I thought it could take years to develop a 100 baseboard route, especially like the one in your photo.

My expectation is that if one were to set out to build a link through a mountain canyon like the one I linked to above, it would would take a significant amount of time to do the first couple, and by the time one got to further into it, generating the terrain part would be relatively quick. Howeverr, I'm not necessarily advocating that all links would necessarily be like the photo! I'd just rather not set "standards" such as "two grid squares flat at the connecting edge of each module" which would make producing a module with terrain like that in the photo very difficult, or perhaps even impossible.

If you want to see such large modules built, surely any routes already on the DLS can be married together with maybe one baseboard between each one for the joins.

I have considered the possibility, but haven't really taken the time yet to research it in any detail. The south end of the Tidewater Route, whether in its intact form, or in just in the "Tidewater South" mode certainly fits my concept of a node, and lends itself to being attached either to other nodes, or to links. I don't mean to suggest, by the way, that one would necessarily have to have a link between every pair of nodes. I would not rule out the possibility of connecting a series of nodes, one of which contains a freight yard, another a passenger station complex, and a number of others, each containing one or more industries within a large urban complex. And the same nodes could be expanded; within the urban area, for example, there might well be a light rail system, or trolley busses which would operate on nodes to complete the urban area.

It seems to me that what you're after, is a way of linking routes with a common theme with a common "coupler". I'm not opposed to that idea at all, and the effort would be minimal for all route builders to implement.. All the route builder would have to do is a have track at each end of the route running off the edge at baseboard level.

What I really want to do is to devise a mechanism that makes it easy for a member of the community to quickly determine how two particular modules might be joined in a route. I see no reason to place a limit on a module: it can be of any size, and have any theme. My feelings are that the system should be flexible enough to that one person can take twelve nodes and link them together to make a model railroad style route, while another can take the same 12 nodes, and using virtual (i.e., iportal) or "real" (modules from baseboards) link modules, create a prototype, or prototype inspired, or free-lance route. I'd also like to see the system flexible enough to accommodate modules built according to current standards (U-Mate, or the digital Free-Mo), as well as standards that might be devised in the future. And I'd hope to see a system flexible enough to accommodate routes not built to any particular standard. Although it is reasonable in the case of tangible HO scale Free-Mo and similar systems to specify connection standards to facilitate assembly into larger routes, is it really necessary in the case of our digital modules? I would argue that it is not. And I would further argue that the ease of adding a board to an existing module or to a new one, in order to facilitate blending, eliminates the need for an arbitrary 2 squre border, and the requirement that each track needs to run off the edge in some particular standard arrangement, although there would be nothing to prevent someone who wanted to create module according to these standards from doing so.

It seems to me that the first thing we need to do is to reach a consensus on what information a person needs to be able to quickly assess how easily two modules can be connected in a certain orientation, and devise a format to present this information in a standardized way.

ns

 

[Johnk]

Okay, you've got the floor. If it were me (and it's not). I'd hit them with a new thread along the lines of: "Making your routes modular". I'd put together my ideas like you've done here and open with a proposal and encourage debate, which I guess you've done here. Unfortunately not enough people are debating. As I said earlier, it would be great if you could expand on your ideas so that those interested are inclined to drift your way. I've always found that leading by example achieves wonderful results. You can easily open a web page or send me your ideas complete with diagrams and I'll create something for you. Screenshots of the Tidewater route and what you have in mind would be handy.

I'm leaving it entirely in your court, but you have my support. Just PM me if you need any help with anything. I won't get involved other than in helping. As my concept was so different, I'll just watch over your shoulder and support you where I can.

Good luck.

 

[StorkNest]

I will keep up with this when I can between real life and the little content creation I do.

Changed the name and rules some.
-First rule now more flexible. You can host a module whereever though it should be listed at least on a main site. Might be difficult to get a module hosted on someone else's site removed but that's freedom for ya and this system is supposed to have less restrictions.
-Second rule changed coding for new name.
-Third rule explains how to tell what items are on DLS even if hosting the module somewhere else.
-Fourth and possible Fifth rule added.

Someday I really have to test the iPortal-to-iPortal thing as that makes joining real easy in TRS2006 and later.

I couldn't make a website to save my life. I tried learning HTML 4.0 once, got as far as a totally text site and pulled it. Doesn't look like I will ever have the time to do website design, that's why I have a simple picture and writing site from MicroSoft, it has file hosting but I rarely use it except for content testing, at least there are no ads.
I could also see asking if TPR would allow a section for this on the Depot if the idea works and John's Directory could list modules and descriptions once things are finalized, I wouldn't ask for stuff to be setup without a finalized plan of action. Thus no extra work financing a whole new site, minimizes effort giving more time for creation if TPR and John allowed it. Why make a whole new site when simply using what's available works.

I don't think U-Make is wasted but those moving to Native mode will have to do a lot of asset swapping to make them work unless new Native mode ones are made. That's part of what developed Rule #2. U-Make was initally developed by eso on these forums but I cannot find his topic anymore.

Texturing at the ends of baseboards to be joined, I'm actually thinking I should add to rule Five these should be untextured for 2 grid squares. The reason is that modules can be designed for different seasons, if someone wants to join modules of different seasons, then they would need a transitional texture and what works between Autumn-Summer won't work between Autumn-Winter. Putting different seasons on the same route is interesting, I've got a model trackplan in a magazine for a coal route with at least four towns and each is done in one of the four seasons going Spring-Summer-Autumn-Winter on a twice around oval, nice concept. I cannot see defining a ground texture set because while there are rules, the purpose was to not have many restrictions on route builders so they can build as suits them like they do with their layouts/routes.

There's no way around the two flat grid rows to avoid weird terrain appearance from someone connecting a mountain module to a flatlands one. You know someone will try. Again if the iPortal thing works, using that could be an exception. Also adding a transition board, some users may be skilled enough to do that but again consider putting a mountain module next to flatland, if the transition was to be gradual, not every user is skilled in Surveyor tools to do that on one board. So for ease of users for now, I'd have to seriously consider leveling baseboard ends to one fixed height. The height doesn't have to be 0 if you list the heights but for ease of non-Surveyor skilled users it has to be leveled.

Module length, I'm just going to insist the baseboard number be listed in the description so route builders can set their own limits and users can decide if they want a big one or not. Also if that iPortal-to-iPortal on the same route trick works, then someone could make one route that starts as one module in initial release but over time is grown to several modules connected through iPortals, can't shut that out. 100 boards could be a module if you build a city, a large yard and some area around it or do what I listed, several modules in one route connected thru an iPortal network.

I couldn't see adding "Link" or "Node" to the asset name. I've seen too much stuff added to asset names that the coding in the name takes up half the name and if long enough, text gets cut off in Trainz. SNC SI TS2009 LM DKG Really Humungous Totally Awesome Superb Pink Shed, way too much, that's why in Rule 2 I limit the coding to identifying what is needed to use it. And I believe users know enough that when they read a description, they know what the module is for. Also Link and Node confuse me because I worked in telecom, I hear Link and Node I start thinking by habit someone's fiber line is jammed or similar, I simply cannot keep the definition described here straight in my head. Maybe my mental hard drive is full. Now listing modules on a site as Link or Node I have no problem with.

I just realized you could have sub-groups under this idea.
A sub-group based on small module restriction.
A sub-group based on a defined ground texture set.
A sub-group based on a certain region or terrain type.
So these are the general rules and if you want certain other rules like those three you just form a sub-group.

Has anyone other than cascaderailroad done the iPortal thing? I just cannot find the time to check myself but it would make some things easy if true.

One thing I want to be clear. The system I started outlining being based on one with fewer restictions (FREE-MO) part of the goal is to make both JohnK and his type happy by allowing small modules but also make mjolnir and his type happy by allowing large ones too. Fewer restrictions also allows route builders to work more as they normally do when making routes/layouts but still has a small rule set allowing module connectivity. End-user picks what he/she wants. Is this more difficult than something like U-Make that aimed for smaller modules with a more defined rule set? Yes, hence why I went public with the basic idea instead of doing it myself, putting out a finished concept and who knows what disaster follows. A big idea with far-reaching aims should be discussed publicly so other viewpoints, prespectives and error-checking can be done. John, I don't think you have to sit back, I see it as your definition fits a sub-group with more defined rules, possibly more like U-Make. I actually think U-Make could be considered a sub-group of this looser idea.

 

[mjolnir]

How much information can we code in how few characters? I've some suggestions regarding the naming conventions in rule 2, so that the identifier includes more information in a concise way.

First, I'd still think there should be an extra digit to the version modifier, so that a 2004 route name is 04, rather than 4.

Second, while nodes can be very large, and links very small,

(This doesn't really quote another post, the quote device is for the convenience of those who might wish to skip the details of the justification) A V-mo module of downtown Chicago in 1950, from Cermak Avenue on the South to Chicago Avenue on the North, and From Cottage Grove on the East (Cottage Grove would be underwater all the way between Cermak and Chicago, but it makes a convenient Eastern boundary, because the area includes Navy Pier, which was still active as a train to ship transloading facility during the period) to Ashland Avenue on the West. This would include all of the major passenger terminals around the Loop, the Loop itself, and the freight action on the North Bank of the Chicago River (most of which was below street level. Now, this area would only be 4 miles square, but as it happens, 4 miles square just happens to require 100 boards--9.777778 boards in each dimension! Now, the CNW and MILW passenger yard complex West of Chicago Avenue, between Lake street and Chicago avenue on the near North West side is a rather smaller a node--16 boards square, but the distance between the two, from Ashland to Western Avenue, where most of the railroad activity is the trains on the parallel multitrack mainlines of the CNW and MILW, might be a link. This is a distance of one mile, or about 2 and one-half boards, all of which is a rather long winded way of saying it's possible for a node to be very large, and a link to be very small.

typically links will be longer and nodes shorter. But a second, and perhaps more imporant difference between links and nodes is that the two groups will generally have different activity profiles characteristics so that it will be useful for users to be able to identify quickly and easily whether a module is a link or a node. Links typically they will be long relative to the width, have more mainline running and less switching activity, while nodes will typically tend to be short relative to the width, and provide more switching than mainline running activity. I suggest that there is value to users if the identifier sequences indicate whether a particular module is a link or a node.

Third, I've gotten two of the "Add-ons", and I wonder how many more add-ons there will be before designating them with a single letter will result in confusing duplication ("I wonder, is that "S" the Settle and Carlisle, or the Suffolk and Chelsea?). I'd suggest just using a single character to indicate content type (built-in, DLS, Freeware, or Payware) in a module.

Finally, I'd add to the module designator some means to indicate region and era.

What I'd suggest for the coding scheme of the identifier is to rearrange it a bit, and add a few more characters to increase the information which can be contained in a glance (and if v-mo modules are contained on DLS, to make searching for them easier).

My suggestion would be that the name of a module would begin with an identifier code nine characters, followed by a caption description. The first character should always be a V, the second and third characters the TRS version, the fourth character an alpha identifier to designate the category of module adding additional valid characters in this slot than just "M". I'd propose "n" as designation for a small node, and "N" for a large one; "L" for a long link, and "l" for a short one; "U" and "u" for large and small modules constructed to Umate standards; and "M" and "m" would be used to indicate larger and smaller modules with multiple characteristics, for example a module which matches Umate Standards at one only one point, or on one axis, but not in the other direction, or at other points. The fifth the century less 18, so that the 19th century becomes "1", and the sixth character the decade. The seventh character would be alpha, and indicate the region, N(orth America), S(outh America) A(ustralia) F(rance). The next to last character would encode a season, where that is a consideration, and The last character would designate content type: built in, DLS, (3rd party) Freeware, or Payware. For example, a module representing a small node in Lyon, France, in winter in the 1950's containing only built-in content and built to 2004 standards might be designated

V04n25FWB-Winter in Lyon

while the link in the same era from Lyon to Geneva Switzerland built to 2009 standards in the summer containing payware content (NB: I would categorize Treez as payware content for any version in which it is not included in the distribution disk or download) would be

V09L25FUP-Lyon to Geneva, Summer.

So, one browsing sees "Lyon to Geneva Summer", and immediately recognized that it requires 2009, represents a link in France in the 1950's, and contains payware.

ns

 

[mjolnir]

I couldn't see adding "Link" or "Node" to the asset name. ...<snippage>... And I believe users know enough that when they read a description, they know what the module is for. Also Link and Node confuse me because I worked in telecom

You're free to substitute another analogy for "link" and "node". My first choice of analogy was "Tinker-Toy®". In this version of the analogy, where links are "dowels" and nodes are "spools". Spools can be connected to as few as one, or a larger number of other spools (I don't remember whether the maximum number was 10 or 14--two on the axis, and balance around the circumference), but a dowel connected to at most two spools. The main reason I changed to links and nodes because I'm not sure how widely distributed Tinker Toys ® were outside of North America, and whether the nuances related to the differences between spools and dowels would be familiar to such readers. A further consideration for coding more information into the module identifier sequence is to eventually make for more efficient sorting of module names in CM and CM2.

edit: Am I becoming too dependent upon CM and CM2? It was some time after posting this that it occurred to me that there is a certain incompatability between questioning whether the value of requiring module to be posted to DLS on the one hand, and wanting to make it easier to search for them in CM / CM2 on the other.

If you're looking for the perfect node, er spool, for a route built in a particular version, you can do a search using "Vxxn", (where x is my proposed 2 digit version identifier sequence), and quickly see whether there's anything available that might suit your needs, without having to scan a whole list.

If you'd prefer a more railroad themed analogy, a node is a yard, and a link is a stretch of mainline between two. A yard can be connected to zero or more other yards by means of mainline segments, but a mainline connects to a yard at either end.

ns

 

[Dap]

. . . If you'd prefer a more railroad themed analogy, a node is a yard, and a link is a stretch of mainline between two. A yard can be connected to zero or more other yards by means of mainline segments, but a mainline connects to a yard at either end.

ns

Or, you could connect several mainline segments together to get a longer distance between yards .

The modules are building blocks that can be assembled any way the user chooses. And each module can be modified any way the user may choose. The important thing is to have a method that clearly and concisely describes the module. We just have to agree on what needs to be described. Then we can develop a coding system.

A few posts back I wrote:

Is it a link or a node?
Size?
Location and elevation of connecting tracks?(north, south east west)
If it is a link, what type of landscape? mountian, desert, farmland, forest, etc.
If it is a node, what does it contain? Industries, yard, passenger station, etc.

I'd like to revise that list.

Is it a mainline or a yard? (Question: Can a mainline module contain a passing siding or a diverging route?)

What size is it?

What are the locations and elevations of the connecting track?

What landscape type, season and era are represented?

What operational content does it contain? (industries, stations, engine facilities, yards, etc.)

I'd like to see this NOT become a domino type module system. Such a system severely limits creativity. Created routes will be predictable and boring.

 

[sparky15]

"Blend boards"

Choose one or two builders, to start, willing to create several varied boards to certain specifications. Kind of like NTrak with a set elevation for scenery, rivers, track, etc. For example flat, hills high, hills low, desert or mountain. Also, pick a set of ground textures, foliage and ONE type of track for these boards. Something like HP Trainz ground textures and trees from Greenery.com for example. These boards can't be modified in any way.

Lets say I build a module. It can be any shape or size I want with anything I want on it. Where I want to join it into the system I'll need a transition board, using the assets above, to join into one of the generic blend boards. That would avoid abrupt scenery changes and make sure my module will fit seamlessly with all the others.

Basically, the only "standards" would be in these boards.

Dave.....