Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Backdating question.
- Thread starter Zeldaboy14
- Start date
Zeldaboy14
Owner of ZPW.
No, what era is TC3 part of? The newer gen engine, or the older gen engine?
johnwhelan
Well-known member
This is been on my mind for a while, and maybe the Trainz Community can solve it for my. Why is backdating a object from Trainz 2012 to Trainz 2010/2009 so simple, but backdating an object from Trainz 2012,2010,2009, Trainz Classics 1 and 2 to Trainz 2006/2004 so hard. I really have never fully understood this.
The biggest problem is scripts, TRS2004-TC3 scripts could clash ie put two different assets on and Trainz would crash, each individual asset was fine by itself. Very difficult to work round. The newer scripts are more robust.
Cheerio John
That's the biggie, but the data model has evolved. Trainz 1.x-UTC expected everything to be in a certain way in a certain suffixed subfolder, '-body', '-art', '_shadow' and so forth, and had very few containers if any in their construction; and further had no tolerance for the raw tga files PEVs tools strip out and make accessible. As aometimes catches me, TRS2006 will take one or the other, but not both. TS09 and up will tolerate both. If you open an asset for edit, you see *.texuture files (binaries), but no raw files. Run PEV's IM2TGA tool and they and the texture.txt files come where we can fix stuff
In TRS2004, most of the same data structures (containers with '{' and '}' wrappers) now necessary to TS09--TS12 were introduced, but at the same time the way things were processed honored the old system and compensated for various data model formats. TRS2006 and the TCs were just as tolerant, but started warnings of tags they'd (N3V) decided were to be eliminated. The TCs mainly advanced Loco modeling, their data definitions and container structures and tags as well as script capabilities, and interactivity, so only those sorts of things created new intolerance's or give trouble retrograding an asset from TS09 & TS10.
In TS09 N3V put what they considered as 'bad things' out as errors since they were too lazy to deal with stripping a line out when parsing the file. I guess retirees using Trainz time was valueless. Why they found it so difficult to just ignore many previously legal keywords is a mystery. Stubbornness, immaturity, and inexperience is the best Jcitron and I can figure--none of the N3V programmers have worked in a large project environment where changes have to be negotiated, or there are formal reviews of proposals and engineering reviews of interim implementations where a dozen or more other brains think critically about the ramifications and implications of said changes.
In a nutshell, they don't think of the Content Creators and User community in general as part of the team and generally ignore such feedback. TANE may be a step a way from it, but if so, they need to prove it to me. (God knows I've hammered them a few times over this nonsense!)
N3V under Windwalkr's questionable decision making, decided to force the 'obsolescent tags' issue and instead of ignoring old tags (name, name-XX, type, region, asset-filename, thumbnail, REM, or leading '//' or ';' which all meant comments are common 'obsoleted' tags causing unnecessary errors--lines the software could just strip out in a few microseconds!) decided to skipped the older way of looking in the folders for certain things entirely, so in fact, many errors are false. The assets are perfectly valid in the older Trainz. Their parsers were smart enough to ignore invalid keywords (DUH! Is it a keyword if it's the first non-whitespace on a line?)
Worse, many FIXES, if the old trainz-build tags are kept are in fact broken. Put a container in a Trainz 1.3 asset, and it won't work in Trainz 1.3! Conversely, on point, to retrograde newer assets to V1.3--v2.4 those same tags will need be created when apropos, especially name and asset-filename.
Trivia: NAME and USERNAME if different show up in different modules with their respective strings. Name will show in Surveyor! Not sure what shows in Railyard.
Further, there is a subset of errors where the textures are in the main folder or body, etc. and the night sub-folder needs it too, but cannot find it and so forth. Those are the can't locate texture errors one sees most often. Bottom line, N3V's programmer's decided that it was their way or the highway and instead of introducing a translation stage then processing an intermediate file when committing, said it must be this way or we're going to call it an error. It is frankly, an flagrant lack of consideration for the user base as all of us have been forced to spend many hours of leisure time getting frustrated and manually patch stuff that a few days of software back-compatibility programming (using code that had been around for years!) could have prevented--and still can. Their behaviors seem to demonstrate they think someone has a perpetual contract to maintain the asset they once made (as a favor to someone else) in the community, such that content creators are perpetual slaves, and never die nor feel exploited and victimized, nor get pissed off nor bored with Trainz. Clearly, keeping the DLS sound and stable has been a low priority, else why create unnecessary error situations?
Many, even most, v1.3--v2-6 assets can be fixed simply by installing a mesh-table, or fixing the path in the config, or the texture.txt file so the dumber newer software can find the right files. Hence, if you "FIX" these non-errors (now called faults--the thing which is broken is the file processing, and the attitude of N3V--these things if downloaded today generally still work in older Trainz releases forsooth, and I have each installed and active to back test!), the 'repaired' asset will likely NOT work in it's native Trainz release anymore. Nice job, N3V, you created a situation where the DLS is incompatible with your own self-adopted role as keeper of the communities shared assets.
TRS2004 & TRS2006 were tolerant of mixing data models, hence bogey0, bogey1, bogey2 etc. could co-exist with a more modern mesh-table and thumbnails, queues, etc. and smart enough to find a texture used in the same asset in another folder, so given the de facto breaking of the asset, I promote such fixed older assets to a trainz-build (+1 usually, 1.3 to v2.3 and 1.5 to v2.5 respectively--and the relative rarity of those two versions in asset populations helps me see fixed assets in CM!) where the container is understood. Note the N3V programming, in effect, created the majority of errors we see on the DLS and cost us all any time we spend fixing such! Hanging Windwalkr and Hilliam is too good a fate. Drawing and quartering, or other medieval punishments are likely too lenient given the inconsiderate cost to others. I don't know how either sleeps at night! I guess in this modern age the hit to their bottom line and reputation is the best we can do,or hope for. I just wish they'd all grow up a bit.
The wonder is the knowledgeable content creators didn't put a stop to it back in 2009... I gather N3V stonewalled, but also note they finally caved in on screenshots and made the error a warning again! It did take a long while though, N3V has 'deaf ears' and passive aggressive behavior perfected. POLITICS is in everything, I'm afraid and the community should have demanded better from them in TS2009--certainly by SP4! I'm confident it's stupid programmer's first, community second design philosophy has cost N3V a ton-a-bunch of customers too, and worse Tony Hilliam seems ignorant of how severely Windwalkr and company have screwed that particular pooch and how simple and easy it would have been to have fixed it without creating the time waste penalties on us users.
(Continued)
INFO: For those unfamiliar, trainz-builds (TBs or v#.#) go in sequence:
v1.3, 1.5 (UTC), 2.0-2.4 (TRS2004), Trainz 1.0, and SP1 and SP2 had no trainz-build codes,
v1.4 was used for Paintshed.
v2.5-2.8 (TRS2006,SP1, TC1&2, TC3) then N3V developed version's:
v2.9--3.3 (TS2009+4 SPs), v3.2--3.7 TS10+4 SPs and TS12+SP1; one TS10 SP pair used same version as it's predecessor, and that an another overlap some of the TS09 versions trainz-build numbers. .
v1.3, 1.5 (UTC), 2.0-2.4 (TRS2004), Trainz 1.0, and SP1 and SP2 had no trainz-build codes,
v1.4 was used for Paintshed.
v2.5-2.8 (TRS2006,SP1, TC1&2, TC3) then N3V developed version's:
v2.9--3.3 (TS2009+4 SPs), v3.2--3.7 TS10+4 SPs and TS12+SP1; one TS10 SP pair used same version as it's predecessor, and that an another overlap some of the TS09 versions trainz-build numbers. .
In TRS2004, most of the same data structures (containers with '{' and '}' wrappers) now necessary to TS09--TS12 were introduced, but at the same time the way things were processed honored the old system and compensated for various data model formats. TRS2006 and the TCs were just as tolerant, but started warnings of tags they'd (N3V) decided were to be eliminated. The TCs mainly advanced Loco modeling, their data definitions and container structures and tags as well as script capabilities, and interactivity, so only those sorts of things created new intolerance's or give trouble retrograding an asset from TS09 & TS10.
In TS09 N3V put what they considered as 'bad things' out as errors since they were too lazy to deal with stripping a line out when parsing the file. I guess retirees using Trainz time was valueless. Why they found it so difficult to just ignore many previously legal keywords is a mystery. Stubbornness, immaturity, and inexperience is the best Jcitron and I can figure--none of the N3V programmers have worked in a large project environment where changes have to be negotiated, or there are formal reviews of proposals and engineering reviews of interim implementations where a dozen or more other brains think critically about the ramifications and implications of said changes.
In a nutshell, they don't think of the Content Creators and User community in general as part of the team and generally ignore such feedback. TANE may be a step a way from it, but if so, they need to prove it to me. (God knows I've hammered them a few times over this nonsense!)
N3V under Windwalkr's questionable decision making, decided to force the 'obsolescent tags' issue and instead of ignoring old tags (name, name-XX, type, region, asset-filename, thumbnail, REM, or leading '//' or ';' which all meant comments are common 'obsoleted' tags causing unnecessary errors--lines the software could just strip out in a few microseconds!) decided to skipped the older way of looking in the folders for certain things entirely, so in fact, many errors are false. The assets are perfectly valid in the older Trainz. Their parsers were smart enough to ignore invalid keywords (DUH! Is it a keyword if it's the first non-whitespace on a line?)
Worse, many FIXES, if the old trainz-build tags are kept are in fact broken. Put a container in a Trainz 1.3 asset, and it won't work in Trainz 1.3! Conversely, on point, to retrograde newer assets to V1.3--v2.4 those same tags will need be created when apropos, especially name and asset-filename.
Trivia: NAME and USERNAME if different show up in different modules with their respective strings. Name will show in Surveyor! Not sure what shows in Railyard.
Further, there is a subset of errors where the textures are in the main folder or body, etc. and the night sub-folder needs it too, but cannot find it and so forth. Those are the can't locate texture errors one sees most often. Bottom line, N3V's programmer's decided that it was their way or the highway and instead of introducing a translation stage then processing an intermediate file when committing, said it must be this way or we're going to call it an error. It is frankly, an flagrant lack of consideration for the user base as all of us have been forced to spend many hours of leisure time getting frustrated and manually patch stuff that a few days of software back-compatibility programming (using code that had been around for years!) could have prevented--and still can. Their behaviors seem to demonstrate they think someone has a perpetual contract to maintain the asset they once made (as a favor to someone else) in the community, such that content creators are perpetual slaves, and never die nor feel exploited and victimized, nor get pissed off nor bored with Trainz. Clearly, keeping the DLS sound and stable has been a low priority, else why create unnecessary error situations?
TANE had better have better parsing or we all need take action--say refusing to submit assets to the DLS until such nonsense is fixed. The dirty little secret is Trainz has never had the best graphics, but the sheer richness of assets made by a willing user community made Trainz the survivor while other simulators failed. Their wealth AND FUTURE is intimately tied to our good will and willingness to feed the free content library. WE DO HAVE power to make them manage better, we just need will to hold off letting them host the free content while letting them know the embargo will continue until such and such is fixed.
Many, even most, v1.3--v2-6 assets can be fixed simply by installing a mesh-table, or fixing the path in the config, or the texture.txt file so the dumber newer software can find the right files. Hence, if you "FIX" these non-errors (now called faults--the thing which is broken is the file processing, and the attitude of N3V--these things if downloaded today generally still work in older Trainz releases forsooth, and I have each installed and active to back test!), the 'repaired' asset will likely NOT work in it's native Trainz release anymore. Nice job, N3V, you created a situation where the DLS is incompatible with your own self-adopted role as keeper of the communities shared assets.
TRS2004 & TRS2006 were tolerant of mixing data models, hence bogey0, bogey1, bogey2 etc. could co-exist with a more modern mesh-table and thumbnails, queues, etc. and smart enough to find a texture used in the same asset in another folder, so given the de facto breaking of the asset, I promote such fixed older assets to a trainz-build (+1 usually, 1.3 to v2.3 and 1.5 to v2.5 respectively--and the relative rarity of those two versions in asset populations helps me see fixed assets in CM!) where the container is understood. Note the N3V programming, in effect, created the majority of errors we see on the DLS and cost us all any time we spend fixing such! Hanging Windwalkr and Hilliam is too good a fate. Drawing and quartering, or other medieval punishments are likely too lenient given the inconsiderate cost to others. I don't know how either sleeps at night! I guess in this modern age the hit to their bottom line and reputation is the best we can do,or hope for. I just wish they'd all grow up a bit.
The wonder is the knowledgeable content creators didn't put a stop to it back in 2009... I gather N3V stonewalled, but also note they finally caved in on screenshots and made the error a warning again! It did take a long while though, N3V has 'deaf ears' and passive aggressive behavior perfected. POLITICS is in everything, I'm afraid and the community should have demanded better from them in TS2009--certainly by SP4! I'm confident it's stupid programmer's first, community second design philosophy has cost N3V a ton-a-bunch of customers too, and worse Tony Hilliam seems ignorant of how severely Windwalkr and company have screwed that particular pooch and how simple and easy it would have been to have fixed it without creating the time waste penalties on us users.
(Continued)
We're not talking about rocket science here, just parsing a text file and picking out key words and paired values. Intro to Computer Science course level programming my sons could have done half-way through their high school intro to programming class. TO BE CLEAR, the bad decision was to not honor the old forms, and concurrently, not ignore "obsolete" tags... (I got a lot of mileage out of region and type sub-filters in running TRS2006 surveyor, so frankly eliminating those was another boondoggle, imho AND preferences, but I digress.)
Similarly unwise and thoughtless, even careless decisions convenient to the programmers, inconvenient to the user community continue to be built-in. Two hotfixes to TS12-SP1 came up after the discussion in the link following. They didn't care to make the fix, so are doubly culpable. The most questionable is this parsing during validation. Just over a year ago Jcitron & I, and Andi06 and a few others in a remarks revolt pointed out the right and easiest thing to do was to preprocess the config, stripping out the tags (like remarks) and just process a preprocessed config.txt interim or use version. How hard is it to A) check if a config.org.txt file exists, and B) if not, copy config.txt, if so, do nothing, then C) process the resultant config.txt and strip out lines you want to not process. TRIVIALLY EASY... Ditto for displaying the longer original file in CM--as if a filename change or choice is difficult to implement--it's built into WINDOWS!
Among other things, the preprocessing (again, very common in computing and just a few milliseconds in time costs) would allow a reverse-parsing checks if there were multiple errors and THAT would pin down exactly where a quoted string was unbalanced--a common and very old technique... apparently rare in eastern Australia. This would immediately eliminate the plethora of errors one sometimes sees where there simple-minded parsing algorithm makes a mess of description or license fields because of an extra or missing quotation, and generate the correct and sensible error sans confusion, and identify where it occurs--if by nothing else, by line number.
A little smarter use of software would even be able to cure things like someone has put a tag and string inside the description block/string accidentally or by forgetting to turn it's double-quotes to single quotes. (i.e. Me, I usually put a change record in the bottom of the description, including moving the obsolete tags now generating errors into said notes. If we had a change-record tag or even REM back, I wouldn't need to clutter that, though it can be helpful as well to see from CM what was changed version to version.)
So to sum up, most errors I've seen are lazy programming (as I've seen in well over 10 gbytes of downloads this past year) AND better programming would have left far more things unmolested, eliminating so many unimportant errors. The model changes V1.5 (UTC) to V2.0 (TRS2004-SP0) were significant and play a big part of errors we see in older content. Other things now create errors such as international alphabets' character sets not honored by N3V, hence the occasional texture file will be unreachable as the *.im or *.pm files call for a file name N3V is stripping characters out of, or mal-translating. Altering one of those (Container2 by HP-Trainz for example) gives you a binary access problem. Patching the im to eliminate the illegal characters would be one fix, but allowing a more extended character set in file names would be another.
Taking the newer general scenery asset back to v1.3 would need a revese PM2IM program, but taking unscripted stuff back to V2.0 is a matter of adapting containers to the older file in subfolder methods. You see these in many older assets, so they should be familiar. I've taken many assets back from TS09 and TS10 to TRS2006, AND the only hiccup in the process is when PEVtools create an Alphahint= line in a texure.txt file. These can be commented as if C++ by prefixing the line with '//' and left in place. TRS2006 (V2.5) will then like the asset fine. If the asset is compatible with V2.5--V2.6 it should work fine in TRS2004, they have the same game engine after all. The file storage would have to be handled manually, and I've not done that, save in musing about trying it out to write knowledgeably for the Wikibook... which is why I have at least one version for every hotfix and SP step (since TRS2004-SP4) up and running.
Next, routes in TS12 changed the data scheme internally, and taking such backwards is very problematic. Lastly, newer scripted assets which don't use software hooks unfamiliar to older versions should work, those which use new tech won't. Be advised, software engineering in each release is the most often changed technology which makes one trainz-build different from the next, so good luck with that! Example: Andi06 developed a crossing last summer that needed the forthcoming change in TS12-SP1+hf4 this last year, so held it up until the hotfix was issued. That sort of software interactive dependency is the kind of thing that can't be made to retrograde properly, but the scenery part of the asset can be take there, or in rolling stock, some part of the script might need be edited to not use such a software call (hook) between the run time software and the scripts.
Now do you see the whys and whens it can and can't be done? Hope this helps. // Frank.
Similarly unwise and thoughtless, even careless decisions convenient to the programmers, inconvenient to the user community continue to be built-in. Two hotfixes to TS12-SP1 came up after the discussion in the link following. They didn't care to make the fix, so are doubly culpable. The most questionable is this parsing during validation. Just over a year ago Jcitron & I, and Andi06 and a few others in a remarks revolt pointed out the right and easiest thing to do was to preprocess the config, stripping out the tags (like remarks) and just process a preprocessed config.txt interim or use version. How hard is it to A) check if a config.org.txt file exists, and B) if not, copy config.txt, if so, do nothing, then C) process the resultant config.txt and strip out lines you want to not process. TRIVIALLY EASY... Ditto for displaying the longer original file in CM--as if a filename change or choice is difficult to implement--it's built into WINDOWS!
(This works, the extra .txt file has no impact. As an example when I fix an error and open a config.txt file, I [ALT]-[TAB] back to the source folder and immediately rename the config.txt a config.org.txt or config.orgFlawed.txt as a routine "Good Programming" practice. [Nice to have a reboot option, so to speak]
Since it's an allowable file type, when the asset is recommitted, the extra file, like an info.htm file [Andi06's suggestion is config.htm] gets compressed to data base format and hurts nothing. When I [ALT]-[TAB] switch back to Notepad++, it tells me the source file has been deleted, and asks if it should retain the file in memory. I say yes and save it ... restoring the config.txt... which I'm about to alter anyway 99 times out of 100)
Since it's an allowable file type, when the asset is recommitted, the extra file, like an info.htm file [Andi06's suggestion is config.htm] gets compressed to data base format and hurts nothing. When I [ALT]-[TAB] switch back to Notepad++, it tells me the source file has been deleted, and asks if it should retain the file in memory. I say yes and save it ... restoring the config.txt... which I'm about to alter anyway 99 times out of 100)
Among other things, the preprocessing (again, very common in computing and just a few milliseconds in time costs) would allow a reverse-parsing checks if there were multiple errors and THAT would pin down exactly where a quoted string was unbalanced--a common and very old technique... apparently rare in eastern Australia. This would immediately eliminate the plethora of errors one sometimes sees where there simple-minded parsing algorithm makes a mess of description or license fields because of an extra or missing quotation, and generate the correct and sensible error sans confusion, and identify where it occurs--if by nothing else, by line number.
A little smarter use of software would even be able to cure things like someone has put a tag and string inside the description block/string accidentally or by forgetting to turn it's double-quotes to single quotes. (i.e. Me, I usually put a change record in the bottom of the description, including moving the obsolete tags now generating errors into said notes. If we had a change-record tag or even REM back, I wouldn't need to clutter that, though it can be helpful as well to see from CM what was changed version to version.)
So to sum up, most errors I've seen are lazy programming (as I've seen in well over 10 gbytes of downloads this past year) AND better programming would have left far more things unmolested, eliminating so many unimportant errors. The model changes V1.5 (UTC) to V2.0 (TRS2004-SP0) were significant and play a big part of errors we see in older content. Other things now create errors such as international alphabets' character sets not honored by N3V, hence the occasional texture file will be unreachable as the *.im or *.pm files call for a file name N3V is stripping characters out of, or mal-translating. Altering one of those (Container2 by HP-Trainz for example) gives you a binary access problem. Patching the im to eliminate the illegal characters would be one fix, but allowing a more extended character set in file names would be another.
Taking the newer general scenery asset back to v1.3 would need a revese PM2IM program, but taking unscripted stuff back to V2.0 is a matter of adapting containers to the older file in subfolder methods. You see these in many older assets, so they should be familiar. I've taken many assets back from TS09 and TS10 to TRS2006, AND the only hiccup in the process is when PEVtools create an Alphahint= line in a texure.txt file. These can be commented as if C++ by prefixing the line with '//' and left in place. TRS2006 (V2.5) will then like the asset fine. If the asset is compatible with V2.5--V2.6 it should work fine in TRS2004, they have the same game engine after all. The file storage would have to be handled manually, and I've not done that, save in musing about trying it out to write knowledgeably for the Wikibook... which is why I have at least one version for every hotfix and SP step (since TRS2004-SP4) up and running.
Next, routes in TS12 changed the data scheme internally, and taking such backwards is very problematic. Lastly, newer scripted assets which don't use software hooks unfamiliar to older versions should work, those which use new tech won't. Be advised, software engineering in each release is the most often changed technology which makes one trainz-build different from the next, so good luck with that! Example: Andi06 developed a crossing last summer that needed the forthcoming change in TS12-SP1+hf4 this last year, so held it up until the hotfix was issued. That sort of software interactive dependency is the kind of thing that can't be made to retrograde properly, but the scenery part of the asset can be take there, or in rolling stock, some part of the script might need be edited to not use such a software call (hook) between the run time software and the scripts.
Now do you see the whys and whens it can and can't be done? Hope this helps. // Frank.
lackoo11111
Active member
Sorry for the necro , but is it possible to backdate a TANE map to work in TS12 ?
johnwhelan
Well-known member
Sorry for the necro , but is it possible to backdate a TANE map to work in TS12 ?
Try it?
I have done one Middleton for laptops TS12 and it worked fine.
Cheerio John
Sorry for the necro , but is it possible to backdate a TANE map to work in TS12 ?
It depends upon the version. After SP2 or SP3, there were changes made to the routes and sessions so that they are parsed in small chunks rather than all at once as they did in TS12 and below. This newer version is what's also used in TRS19 and up, and breaks TransDEM's ability to modify later TANE and TRS19 and above routes.
Similar threads
- Replies
- 1
- Views
- 577
- Replies
- 68
- Views
- 6K