norfolksouthern37
what's a normal map?
i think a majority of the files were not made right to begin with, not that the standards 'keep changing'.
Is this all a mess or no?
- Thread starter novastorm2000
- Start date
novastorm2000
Member
Cows appear to already be home!
Welcome everyone to your end result!
Effort expended = Little
Reward gained = Nothing
Naysayers Win!
The prize is! Drum Roll .............
Zippo!
E
Last edited:
Some things I've read while waiting for my 2010 to arrive:
(From the asset error fixing guide for 2006)
(Edit: Talking about alpha textures IIRC.)
From TrainzDev Wiki:
Also I saw a post talking about "progressive" meshes not being supported (though the version of Trainz used wasn't mentioned, I assume it was a recent one) with a suggestion to use a LOD mesh instead. So from these examples, which I've found without even really looking into content creation, it looks like the standards do change from one version to another.
norfolksouthern37
what's a normal map?
the 09 'requirements' were only for submitted items for release. you dont need either of those things just to make an asset now.
i would say that since TRS2004 things have been generally the same. all of that you mentioned has been in place since that version, the 'errors' that pop up now are usually because they crack down on what they accept. lots of malformed content has made its way in since then from people who made up their own scripts or config tags etc that do not conform to the standard. and they did this just because they were not told they shouldn't.
i would say that since TRS2004 things have been generally the same. all of that you mentioned has been in place since that version, the 'errors' that pop up now are usually because they crack down on what they accept. lots of malformed content has made its way in since then from people who made up their own scripts or config tags etc that do not conform to the standard. and they did this just because they were not told they shouldn't.
johnwhelan
Well-known member
It's a bit of both. Some methods change over time some errors were difficult to detect in earlier versions but TS2009 threw them up. Sometimes what was acceptable in previous versions ie no shadow suddenly become an error, or BlueStar couplings and icons for example.
Whatever the reason we have unclean data and normally for something like this step one is clean the data up and its step one we don't seem to be able to do.
Cheerio John
John , I agree -
As I stated previously , the problems started at the beginning and were never addressed , now it is inconceivable to me , that there is the time and the manpower to set it right !
A fix , it ain't gonna' happen' -- Just my thoughts --- ,DLR
I think the word you're looking for is "realists."
Frankly you sound like a project manager, full of good ideas with no idea of how to implement them, or what is involved in doing so. You can't just throw together a php website and a database when the fundamental problem with the DLS is that of data quality. The programming adage "cr*p in, cr*p out" springs to mind - it doesn't matter what front end you put on it, the results are only as good as the data. In this case the data is not very good.
There are some things which could be done with Cron jobs:
1. Any asset on DLS which requires any dependencies which aren't available on DLS is automatically deleted from DLS.
2. Any asset on DLS with common errors in its config.txt file which can be automatically fixed using similar logic to that in Trainz Objectz has them fixed. This would only be the modern equivalent of a traditional human editor correcting spelling and typing mistakes, so copyright wouldn't be a concern.
3. Any asset on DLS which cannot be automatically fixed so as to work in TS2010 (native mode or compatibility mode) without any errors or warnings is automatically deleted.
The same needs to be done with all the built-in assets in the next TS2010 service pack.
John
1. Any asset on DLS which requires any dependencies which aren't available on DLS is automatically deleted from DLS.
2. Any asset on DLS with common errors in its config.txt file which can be automatically fixed using similar logic to that in Trainz Objectz has them fixed. This would only be the modern equivalent of a traditional human editor correcting spelling and typing mistakes, so copyright wouldn't be a concern.
3. Any asset on DLS which cannot be automatically fixed so as to work in TS2010 (native mode or compatibility mode) without any errors or warnings is automatically deleted.
The same needs to be done with all the built-in assets in the next TS2010 service pack.
John
I think you'd annoy all the 2004, 2006, TC3 and 2009 users if you went and deleted all their content! You are correct, though, a great many problems could be fixed automatically.
johnwhelan
Well-known member
Trouble is routes where one or two scenery items are not on the DLS. I like the approach but unfortunately it would mean dumping a lot of assets where the content creator is not available to do the fixes.
Cheerio John
novastorm2000
Member
Thats real helpful feedback and as for garbage in garbage out (GIGO), why do you think we are having this conversation. There is a huge difference between realist and pessimists, I see a lot of the latter here because everyone is focused on why it can't be fixed instead of what can be done to begin to fix it.
The problem with todays culture is that people expect instant gratification, so if any work is required or time to undo what has taken years to get messed up, then its just deemed as unrealistic, undoable, never will work.
There is nothing here that can't be fixed with time and effort and with more can do it attitude. If Auran fixed it in the next release there would be a lot of happy people.
Have you actually read what really being said here? A database effort focused on data cleansing and quality would be very doable and pretty easy to implement. Even a batch utility for users to utilize the improved data to cleanup their own local installs using the public asset data would not be all that hard and people could continue to use the Auran tools.
It really depends on what people want and are willing to do. Even just a database where people show all the correct information, assets, owners and compatibility would help people.
What is happening here in my humble opinion as it all to often does in forms is that egos and opinions without facts are ruling the day. People will insult each other and have no idea who each other are. Its the ugly side of forums rearing its ugly head because most people would never dare treat each other the way they do here when they have no real accountability for what they say and do.
So, as I said, at the end of all this, we have nothing and nobody doing anything on a topic that has obviously interested a lot of people because its a real problem.
Its kind of like complaining about a leak in a house and then chasing all the people away who would help you fix the leak and standing there saying it can never be fixed.
Peace Out!
E
I think it is the dumping part that is drastic. Perhaps downgrading to a lower version would also work. Even if the author claims it is for TS2010, if it only works in TC or TRS2006, or even TRS2004 for example, that is how it should be categorized. For those where the correct version can not be determined, create an unknown version with a suitable warning.
Because all previous Trainz versions are still being used, there is no need for every asset on the DLS to be compatible with only TS2010. In fact, simple but useful assets could be compatible with almost all versions so their announced version could be UTC but still be usable in TS2010.
What is needed on the DLS is a way to indicate that an older asset is compatible with a newer version of Trainz. Since the creator of the asset might not know this at the time of creation (either because the newer version is not released yet or because he doesn't have a newer version), a way needs to be found to retrofit older config files to show version compatibility or add a tag in the DLS sorting system to show this information. This way, everyone would know before downloading an asset if it is compatible with whatever version of Trainz they have, even if the asset was originally made for a previous version of Trainz.
Excellent idea, but of course it would make the cleansing program rather more complex.
John
Already done. For TRS2004 users the third-party Trainz Objectz utility automatically fixes a lot of the common errors in config.txt files. However, TRS2006 and later use a database asset management system which isn't compatible with Trainz Objectz.
John
It's not a case of instant gratification - we all want a fixed DLS, but we are not in a position to do it.
You keep saying how easy it is to do what you are proposing, and we keep telling you it isn't. Blind optimism doesn't write software - we don't have Auran's database format, rights to upload corrected data, permission from content creators to modify assets, an official, complete specification for asset creation so we know what "correct" really means... the list goes on. And trying to create some kind of secondary database of correct information is going to fragment the DLS and confuse new users, who will see two sets of information for the same asset.
I'm sorry, but I think that's nonsense. I can't see how egos are involved, other than you ignoring whatever facts are given to you because you don't agree. You're displaying more ego than anyone, and your opinions are flying in the face of any facts you are given.
I've love a corrected, easily searchable DLS, but we are not in a position to provide it.
novastorm2000
Member
your not responding to what I am writing even.... And that's pretty much my point and all the more I'll say.
E