PDA

View Full Version : Backdating question.



Zeldaboy14
June 20th, 2014, 12:17 AM
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.

nicky9499
June 20th, 2014, 12:43 AM
1.3 -> utc, 1st gen engine
04 -> tc3, 2nd gen engine
09 ->12, 3rd gen engine

Zeldaboy14
June 20th, 2014, 12:46 AM
Ahh, but why would the game be moved to three engine's over the course of Trainz? I mean, New Era is a completely scratch built engine, and is the 4th engine that the game is going to be on, but why have the past 2 been basically the same as gen 1's engine?

nicky9499
June 20th, 2014, 12:53 AM
but why have the past 2 been basically the same as gen 1's engine?

Do you want to reconsider this (possibly ignorant) statement?

http://www.uktrainsim.com/getthumbs/n/NeutronIC/trainzsp3.jpg


http://imageshack.com/a/img838/9122/tjp6.jpg

pcas1986
June 20th, 2014, 01:12 AM
Deliberately making content for earlier versions of Trainz is only going to give you a future maintenance problem. So, unless there is a particularly good reason I don't see the point. I might make an exception for TS10 since a lot of folk have problems with TS12 but that's it.

Hopefully T:ANE will be so good that folk will want to give up using TS04, TS06, etc. Don't get me wrong, I loved TS04, and especially the little Ooom guys, but I prefer to use the latest version.

Azervich
June 20th, 2014, 01:28 AM
You can see a big difference in the two Screenshots posted.... I think TS12 has a newer engine as the details look better than TS09/10, especially how it has speedtreez.

If T:ANE is better in details, physics, and able to render large high poly scenery spots then I'll probably end up moving the Geelong-Queenscliff route I'm working on to T:ANE rather than TS12 PRE-SP1 along with WIP Steam Locomotives and rollingstock.

TS09 is soon to have it's support removed so it'll be just 10, 12 and T:ANE.

Cheers.

alexl102
June 20th, 2014, 04:17 AM
It's all very well saying that we hope T:ANE will be good enough to finish off 04/06 for good but the other side of that is that many people won't have a computer capable of running it. I'm not having a go at the creators when I say that (I'm genuinely thrilled that they're going all out to create something so epic even if it is more demanding on computers), I'm just stating a fact! But hopefully people will at least move up to 10 or 12.

cascaderailroad
June 20th, 2014, 05:12 AM
My advice is to build routes in lower versions 04, 06, UTC, and use them as a simplistic surveyor route building tool only ... and import the routes into 09, 10, 12 or T:ANE

nicky9499
June 20th, 2014, 05:53 AM
Excellent advice as usual Cascade. Through this technique the user will also get to experience the joys of 10m grid, old and/or outdated content and missing dependencies on import. I'm surprised nobody else does this.

jeff1959
June 20th, 2014, 10:51 AM
Deliberately making content for earlier versions of Trainz is only going to give you a future maintenance problem. So, unless there is a particularly good reason I don't see the point. I might make an exception for TS10 since a lot of folk have problems with TS12 but that's it.

Hopefully T:ANE will be so good that folk will want to give up using TS04, TS06, etc. Don't get me wrong, I loved TS04, and especially the little Ooom guys, but I prefer to use the latest version.

I think that one reason people will NOT give up using older versions is economics. For example, I use TS10 because I couldn't afford TS12. Since I enjoy 10, I see no reason to spend MORE money to update. There are plenty of reasons why people don't upgrade, and cost is often the main one. Even though you might argue that WIN 7 is better then Vista or XP, if you use XP and it works for you, why spend the $$.

So, I don't upgrade to TS12. Why can't I have updated goodies?

JCitron
June 20th, 2014, 11:16 AM
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.

Much of this has to do with scripting and other game engine features that are not available in the earlier versions. Some stuff made for TRS2004, for example, had product queues for use with interactive industries. This will not work in previous versions without hacking out the script from the assets. There have also been some graphics changes such as the way alpha channels and normal maps are now handled. This was unheard of in the earlier versions, and the references to these files causes errors in the assets.

Granted, with some work, some of the more basic assets can be backdated, but why would you want to use a much more unstable product? Even with all its warts and bumps, TS12 is a far better product than UTC or even TRS2004. Many people here forget the hassles we had with the earlier products and yearn for the olden days through rosy glasses and bright lights. TRS2004 was not the best product until SP4 came out, and then that was beat out later by TRS2006, which was built on TRS2004 but with more features. Sure these programs can run on lesser hardware and take up less space, but so do many things. Remember too that there were less capabilities built into them in the first place. A good example is traffic. Up to TRS2004 SP1 road traffic went up elevators or stairs instead of following the terrain. We were warned at the time this was pushed by the community that it would have an impact on performance. We laugh at things such as this today, based on what we have for computers, but at the time these programs were bringing that very hardware to its knees. In fact up to TRS2009, there was a buffering data bar that would appear. In TRS2006 and up through TS2009, this was an option in the trainzoptions.txt (I think...), but prior to that it was always visible. This bar would show up when data was being loaded, and would persist on the screen when things got a bit rough on the computer. Probably today this wouldn't appear with the older products, and since then it has been deprecated as an option.

Yes like any product, whether it's computer software or a tangible good, the previous version is usually the basis for the newest release. If it wasn't for this, we'd still have version 1.0 of everything. So even pianos, automobiles, even light bulbs and computers will have some old stuff in them from previous versions. In fact pianos are based on technology that was initially designed and invented in 1700! It took another 120 years before the modern escapement was developed by Erard, and another 45 years after that for the first full ironl plate to be created by Chickering from Boston. The action of a mid-19th century grand piano is the same, or very similar to what is found in a modern instrument. Action in a late 1880s piano is exactly the same. The differences are some improvements in materials and tolerances, but the mechanical design is pretty much the same. We can say the same for railroads and the development of the various components. Yes, technology has changed but the underlying principals of engineering are still there. Even electrical service and the theories behind AC transmission are the same. I recently came across my great grandfather's engineering books from the early 1920s - he was an electrical engineer for the Boston Edison Company. His books have the same theorems I learned while I was taking electrical engineering classes in 1980!

John

nicky9499
June 20th, 2014, 11:20 AM
So, I don't upgrade to TS12. Why can't I have updated goodies?

Are you being serious?

That like saying "I drive a 1980s Ford Fiesta. Why can't I have an Ecoboost motor, climate control, cruise control, satnav, bluetooth and a Bose surround sound system?"

Unbelievable.

JCitron
June 20th, 2014, 11:46 AM
Are you being serious?

That like saying "I drive a 1980s Ford Fiesta. Why can't I have an Ecoboost motor, climate control, cruise control, satnav, bluetooth and a Bose surround sound system?"

Unbelievable.

Yup... and he's still using one of these for his gaming.

http://cdn2.bigcommerce.com/n-pktq5q/ymgqt/products/31027/images/21904/System-Atari-2600-2cont-2__23199.1394748611.210.210.jpg?c=2

John

Fabartus
June 20th, 2014, 05:15 PM
Are you being serious?

That like saying "I drive a 1980s Ford Fiesta. Why can't I have an Ecoboost motor, climate control, cruise control, satnav, bluetooth and a Bose surround sound system?"

Unbelievable.
You know there are ways to let someone know they haven't thought it through without always being a sarcastic ass. Think it through. // Frank

jeff1959
June 20th, 2014, 05:17 PM
Yup... and he's still using one of these for his gaming.

http://cdn2.bigcommerce.com/n-pktq5q/ymgqt/products/31027/images/21904/System-Atari-2600-2cont-2__23199.1394748611.210.210.jpg?c=2

John

I was going to respond to this, but I refuse to get into a battle of wits with someone who's half-armed.

NSWGR_46Class
June 20th, 2014, 05:53 PM
Back dating an item of content might also be outside the liceance and creators wishers.

I get at least 5 emails a week from people who are trying to run locomotive in a version of trainz it is not designed and are wanting my help to get it to work for them. My replies are often quite curt.

Zeldaboy14
June 20th, 2014, 05:55 PM
Do you want to reconsider this (possibly ignorant) statement?

http://www.uktrainsim.com/getthumbs/n/NeutronIC/trainzsp3.jpg


http://imageshack.com/a/img838/9122/tjp6.jpg
Well, I never played the original TRAINZ, so what would I know? :p Like I stated in about 20 other posts before, I was introduced to Trainz because 1: SI3D Films and 2: Trainz 2006 Driver and Hawes Demo's.

pcas1986
June 21st, 2014, 03:34 AM
I think that one reason people will NOT give up using older versions is economics....

Yes, that's a valid reason, and even more so for the potential hardware cost upgrade as someone else pointed out. My apologies for not considering that. It's been a while since I had to live from payday to payday.

Note that I still have TS04 in its box plus every other version in the banner with my name. But I only have TS10 and TS12 installed. Every version was outstanding in its day.

cascaderailroad
June 21st, 2014, 09:36 AM
04, 06, UTC, TC1&2, TC3 will run on low end integrated graphics PC's ... 09, 10, 12 will not

09, 10, 12 have speed trees, and complicated layers ... 04, 06, UTC, TC1&2, TC3 do not

Zeldaboy14
June 21st, 2014, 12:38 PM
Where's Trainz Classics 3 on that list cascaderailroad?

nicky9499
June 21st, 2014, 01:00 PM
It's on his games shelf and he forgot to count it when he was writing that post.

Zeldaboy14
June 21st, 2014, 01:03 PM
No, what era is TC3 part of? The newer gen engine, or the older gen engine?

nicky9499
June 21st, 2014, 01:11 PM
TC1 and 2 were basically TRS2006 with localized content focused on specific regions. TC3 had a few more significant improvements and can be considered as far as the 06 engine went. The engine in TS09 onwards what you're using now, the biggest improvement being the 5m grid.

johnwhelan
June 21st, 2014, 01:50 PM
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

Fabartus
July 31st, 2014, 08:50 PM
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


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





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)

Fabartus
July 31st, 2014, 09:04 PM
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 (http://forums.auran.com/trainz/showthread.php?103395-The-ability-to-add-comments-to-config-txt-files-This-was-removed-in-2-9-and-up&highlight=comments)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)


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.