Tagging older less efficent content

[johnwhelan]

I'm tempted to change the "name" on some scenery content to "outdated name" its mainly on the performance side to save anyone from using it on a new layout, the kuid would still be there for existing layouts.

Thoughts?

Thanks John

 

[JCitron]

I'm tempted to change the "name" on some scenery content to "outdated name" its mainly on the performance side to save anyone from using it on a new layout, the kuid would still be there for existing layouts.

Thoughts?

Thanks John

John this is actually a good idea. You could use something like [deprecated] or [obsolete] in the name with an updated description.

John

 

[mjolnir]

I really like the idea, but have rather less affinity for the proposed nomenclature. My problem with the nomenclature is that a modern building, bridge, or rail asset where the prototype was constructed in 1998, and which was modeled in UTC, or 2004, would not be up to standard, but it's not really "outdated", conversely, an abandoned store where the prototype was built in 1882, and was modeled to current modeling standards, could be called "outdated", too.

Maybe the "ratings" column in the content manager could be given a dual purpose. Besides the purpose I perceive it currently has, give a second set of ratings, "resource consumption", which could be used to indicated assets which have particularly high poly meshes, or poorly written scripts, or other issues which might cause a degradation in performance.

Of course, the problem with that suggestion is that the ratings may not reflected railyard, or surveyor.

ns

 

[johnwhelan]

So a tag of "less efficient" in front of the name would be acceptable and less likely to be misinterpreted?

Thanks John

 

[RRSignal]

Yeah, that's a good happy medium.

 

[Dermmy]

So a tag of "less efficient" in front of the name would be acceptable..

LOL - yes, but you need a more efficient prefix! If you put a prefix that long in front of the actual name then in Surveyor it is going to be too big for the menu flyout (unless the actual name is very short). I hate assets where the only way to read the full name is mouseover...

Andy

 

[Dinorius_Redundicus]

I hate assets where the only way to read the full name is mouseover...

Andy

Big ditto on that one!

Since Trainz relies so much on the first word on the username field for alphabetic sorting and keyword search, I would suggest any marker in the name be a suffix not a prefix. Perhaps just a 2- or 3-letter code, something that is easily remembered and likely to be found in a search. Like XX or !! It could always be explained in the description section.

 

[johnwhelan]

So "LE" in front of the name? That would tend to sort them to one part of the list.

Actually does it really matter these are items that you would be much better off not using, pre TS2009 performance discussions. If they have been used on an existing route you wouldn't see the name anyway.

Cheerio John

 

[Pendolino]

It could be nice to add a feature to the CM computing a numerical value proportional to the "weight" of each piece content, taking into account the number of polygons, the number and size of textures, the use of LOD and any other significant element. After all, Trainz already does this in Surveyor, indicating the worst piece of content in view, so it has to somehow evaluate the impact of all the other elements.

I imagine something like this:

Index = #polys + 300*(#textures-1) + overall texture size in KB.

To make some very rough examples:

- a 12-poly cube with a single (very inefficient) 1 MB 100% green texture will have a index equal to 1012; the same cube, with a 2 KB 100% green texture will have an index value equal to 14.
- a simple 60-poly house with three texture (1 MB total) will be rated at 1660 (60 + 300*(3-1) + 1000). The same house, with a single 1 MB texture, will be rated at 1060...

The values above are just indicative; I am sure that 99% of the Trainz users are more computer literate than me and can formulate something more meaningful...

Using this method with proper consideration for all the elements contributing to the efficiency of a piece of content, however, and adding a filter in both CM and Surveyor, it would be easy to get rid of any badly designed, not efficient (but not necessarily older:hehe: ) content, such as 10,000 poly dust bins with a dozen different textures...

 

[JCitron]

It could be nice to add a feature to the CM computing a numerical value proportional to the "weight" of each piece content, taking into account the number of polygons, the number and size of textures, the use of LOD and any other significant element. After all, Trainz already does this in Surveyor, indicating the worst piece of content in view, so it has to somehow evaluate the impact of all the other elements.

I imagine something like this:

Index = #polys + 300*(#textures-1) + overall texture size in KB.

To make some very rough examples:

- a 12-poly cube with a single (very inefficient) 1 MB 100% green texture will have a index equal to 1012; the same cube, with a 2 KB 100% green texture will have an index value equal to 14.
- a simple 60-poly house with three texture (1 MB total) will be rated at 1660 (60 + 300*(3-1) + 1000). The same house, with a single 1 MB texture, will be rated at 1060...

The values above are just indicative; I am sure that 99% of the Trainz users are more computer literate than me and can formulate something more meaningful...

Using this method with proper consideration for all the elements contributing to the efficiency of a piece of content, however, and adding a filter in both CM and Surveyor, it would be easy to get rid of any badly designed, not efficient (but not necessarily older:hehe: ) content, such as 10,000 poly dust bins with a dozen different textures...

I feel like I've just been to an Algebra class!

There is a car going east at 70 mph and a train going west at 110 mph...

John

 

[Dinorius_Redundicus]

So "LE" in front of the name? That would tend to sort them to one part of the list.

Actually does it really matter these are items that you would be much better off not using, pre TS2009 performance discussions. If they have been used on an existing route you wouldn't see the name anyway.

Cheerio John

Well I don't like the idea of a prefix for the reasons stated above. And I don't think LE is a particularly good choice because too many regular words have that letter combination somewhere in them (Lehi, Settle, bottle...whatever). I'd punt for something more unique and at the end of the name not the beginning. As for grouping them, well we have name/keyword filters to pick them out. Just my opinion of course.

 

[Euphod]

As long as the name isn't "car", then you would have "Le Car"...

 

[johnwhelan]

Well I don't like the idea of a prefix for the reasons stated above. And I don't think LE is a particularly good choice because too many regular words have that letter combination somewhere in them (Lehi, Settle, bottle...whatever). I'd punt for something more unique and at the end of the name not the beginning. As for grouping them, well we have name/keyword filters to pick them out. Just my opinion of course.

I was thinking of the front so that they grouped in surveyor, tag the end and people won't notice.

Cheerio John

 

[johnwhelan]

It could be nice to add a feature to the CM computing a numerical value proportional to the "weight" of each piece content, taking into account the number of polygons, the number and size of textures, the use of LOD and any other significant element. After all, Trainz already does this in Surveyor, indicating the worst piece of content in view, so it has to somehow evaluate the impact of all the other elements.

I imagine something like this:

Index = #polys + 300*(#textures-1) + overall texture size in KB.

To make some very rough examples:

- a 12-poly cube with a single (very inefficient) 1 MB 100% green texture will have a index equal to 1012; the same cube, with a 2 KB 100% green texture will have an index value equal to 14.
- a simple 60-poly house with three texture (1 MB total) will be rated at 1660 (60 + 300*(3-1) + 1000). The same house, with a single 1 MB texture, will be rated at 1060...

The values above are just indicative; I am sure that 99% of the Trainz users are more computer literate than me and can formulate something more meaningful...

Using this method with proper consideration for all the elements contributing to the efficiency of a piece of content, however, and adding a filter in both CM and Surveyor, it would be easy to get rid of any badly designed, not efficient (but not necessarily older:hehe: ) content, such as 10,000 poly dust bins with a dozen different textures...

But you also have to take into account size, I have a few blocks of 48 houses which have a higher poly count than one house.

Cheerio John

 

[narrowgauge]

Why not just add a zero or a nine to the beginning of username. This will automatically sort to the end of the surveyor listing.

Peter

 

[johnwhelan]

Why not just add a zero or a nine to the beginning of username. This will automatically sort to the end of the surveyor listing.

Peter

I like this idea.

Thanks John