Free-Mo modules for Trainz?

[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]

Originally Posted by StorkNest

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]

Originally Posted by mjolnir

. . . 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.....

[Johnk]

These are not suggestions, just observations.

Snippet: 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.

If you don't want a domino system, you may as well all settle on a specific route and each build a section. I'm not suggesting 50 miles of track before something happens, but truncated in some way so that each builder has at least one decent yard, station etc., in his here section. They could and should be allowed to use their noggins and add more, but if a more specific scene was set (i.e. Rio Grande scenery, not the railway itself) the overall route would blend together much better.

Using Sparky's (and I think Storknest's) blend boards take away the advantage of "plug and play" which I had invisaged in my original suggestions. I originally saw this project as a way "drivers" could build different routes by moving modules about. It would be simple enough to show people how to do that, but Blend Boards will require a "driver" to become a "builder" and aquiire additional Surveyor skills. Many will not want to do this, so my original vision is totally lost. Such is life.

[sparky15]

You would still be able to do that. It would be up to me, for example, what size I would like to build. Be it one board or twenty. Having a set of pre built boards to go between say my module and yours just makes sure they will be able to be merged easily by anyone who downloads them. By starting with a pre set standard, you wouldn't necessarily need something to go between the two, since we both matched our modules up to it. Even the basic contours and and scenery would be close where they join since we both started from a pre set.

Dave....

[mjolnir]

Originally Posted by Dap

Question: Can a mainline module contain a passing siding or a diverging route?

In my view, the short answer is "yes, a mainline module might certainly contain a passing siding, a diverging route, a small passenger station, or an industry, just as there would likely be mainline on a yard module. If one considers all of the rail activity on the route, if more of the activity is running a train across the route, than switching yard or industrial tracks, then I'd consider it a mainline module; if more activity is switching industry or yard tracks than running through trains, I'd consider it a yad module. In any event I'd hope that the designation "yard" or "mainline" would be considered to be descriptive, and not prescriptive.


And I'd also add to David's list,

If there is water on the module, what is it's elevation relative to the base elevation of the module?

[Dermmy]

Originally Posted by mjolnir

If there is water on the module, what is it's elevation relative to the base elevation of the module?

You have to suspend disbelief on a modular route. If you go from a plains area to a Swiss Alps area it is probably easier track-gradient wise to take the valleys down rather than the track up, so 'sea level' on two modules could be hundreds of feet apart. Does it matter?

Andy

[mjolnir]

Originally Posted by Dermmy

You have to suspend disbelief on a modular route.

I agree that one needs to suspend belief if one is working with plywood, styrofoam and nickel silver; I'm not so sure if this is the case if one is working with virtual modules. In the latter case, I see the question as more of "how many boards to I have to add to maintain, or create, believability?".

But it seems to me that as easy (at least physically) to add a board to a route, the details of the interface are somewhat less important. So maybe we're making this more complex than it really needs to be. What are the minimum questions to which I need an answer about whether, or how easily two modules can be connected? These are the answers I have concluded at this point that I would need to know. I expect there are others, but I don't yet know what they are.

0) Trainz version.

1) Can it be connected to something else without altering the module? Some model railroads (for example the built in Marias Pass can be connected to by removing the portals; the built in "City and Country-USA" and "Highland Valley" routes cannot be connected as they are closed loops.)

2) Defining a "track interface" as a baseboard side on which a track leaving the module crosses, how many track interfaces are on the module, and where are they. For example, I have a 1 x 3 boards module, all oriented North and South, upon which a branch line of one railroad terminates, and through which a mainline of another traverses. The mainline has two track interfaces, one crossing the South interface, shifted off center to the East; the other leaving the module on the East side, quite close to the north end of the East side. The only track interface of the branchline is quite close to the East side track interface of the mainline. Now, it seem to me the ease of making a board is such that it is not really necessary that a person needs to know the details of the track interface, but it would be useful to someone looking for a module with a track interface on the west side of the module that my module does not have one.

3) Some notion of the terrain type would be useful to know. Is the module urban or rural? What is the character of the landscape, rolling plain, or mountains?

4) Absolute altitude of the module base elevation relative to the default altitude of a "new" board.

5) Relative altitude range, how far above and below the scenery extends relative to the base altitude of the module.

6) Presence of interactive industries (and if they are present, what they are).

7.) Content type--region, era, built-in, DLS, 3rd Party Freeware, payware; mainline, or yard; prototype or free-lanced; scale--12in/ft, O, HO, N.

If I have the answer to the above categories of questions about each of two modules, I expect that I'd be able to make an assessment of the connectability of those two modules; all the rest is details. The advantage of Umake and V-mo, and all the rest lies in the fact that imposing the standards, they answer most of the above questions, and guarantee interconnectability. But the ease of adding a board, and the speed with which a board could be roughed in in TRS means that interconnectability is not as important, as it would be if we were crawling around on our hands and knees on a concrete floor, trying to clamp modules together.

ns

[Johnk]

A screenshot of each end of the layout, taken from a reasonable altitude and another of a typical feature would show most of the things you mention. That's not possible with the current DLS, but if people got off their butts and used the facilities offered in the Trainz Resources Directory, it wouldn't be a problem. The route and all assets would still be stored on the DLS, and the listing in the Directory would be linked to this (or these).

People looking for modular routes would soon learn where to go to seek information, your modules would be properly represented and many of the issues you're raising would be instantly solved.

Here's a sample with video.
Here's one without video
And another.

The only difference here is that these are routes, not modules, and the information may be a little loosely structured for what you need. Neither are the routes linked to the DLS. None of those issues are my fault. I can only work on information supplied to me.

By the way, the first route was the second most the most visited page on my site last month. With 312 views it was indeed popular. The other two routes were also in the top eight listings.

This indicates to me that people are looking for this kind of information.

John