Content Creator Plus
edit
Content Creator Plus (or more often CCP on the forums) is a asset creation and editing tool envisioned as a strict syntax enforcer; a software module introduced along side 'Content Manager Plus— (CMP) in TRS2006 in fall 2005. Like each release's CM version, each had their own CCP with capability of handling or enforcing progression of the Trainz data model; generally version to version, these are only slight evolutionary changes in how data is organized and expected to be presented going forward.
Each CCP was directly launched by the CM/CMP right-click (Select-and-Do) pop-up menu until the TS2009-SP4 release in 2012. With the progression of TR06's CMP thru the years up through TS12's CM 3.7 upgrades, each new CM would get pickier about what tags and containers it accepted in legacy assets' translation to the effective (run time) data model. In effect, certain prior practices and default understandings were made illegal, almost always unnecessarily—and this voluntary N3V procedural practice, in effect, created faulty content messages because the new CM was changing the rules... when merely honoring the older practices' defaulted data definitions would still be workable.
| --> The proof is endemic and readily testable: Just make a minor change such as installing a mesh-table to a older asset and update the trainz-build value (TBV) to the next releases' native-minimum-TBV — in effect, this minor change is an 'data-type upgrade' although relative to the functionality of the asset rendering, has effectively zero run-time difference, so is indiscernible to the eye. It might conceivably have a very very minor effect on the asset's GUI-fetch-and-load-asset into pre-renderable memory timing, but once in the run-time asset list, that asset's binary form will be rendered at need the same way regardless of release. Most such changes are cosmetic, or data placement (e.g. tag or tag functionality made a parameter inside a container instead of the main body of a config) — as experience with 'fixing older assets' will generally prove. They are an example of trying to attain an unnecessary ideal in the read and save a RUN-TIME version as-quick-as-possible that mistakes when and where such interpretations can and should occur. [note 1]
|
|
Specifically, CCP was a text processing syntax checker and file/folder test tool that tried to enforce ideal data configurations using the most up to date data preferences. The long term benefit to CCP was that it forced strict compliance with the most up to date acceptable data model (i.e. To The Highest TBV tags and most up-to-date data structures preferred by the Auran/N3V's programmer's up to the technical level supported by that release's explicit TBV and applicable therefore in testing assets as the high end requirement defining acceptable coding within the config.txt file's data. The problem with this was exacerbated by N3V when they introduced the Trainz Life-Cycle Policy and increased fault testing of the uploading of assets—the fault testing required old data structures to be manually eliminated to newer TBV practices, just as did each CCP release, but the great majority of such changes is inconsequential, name changes, translate-data to French, Italian, or Albanian, and so forth. For several years, CM and the DLS required thumbnails be made for assets but only those using texture.txt file methods were kept in DLS versions... the whole process was rife with unnecessary enforced requirements creating strife and unnecessary time expenditure by asset creators—The Trainz Communities most valuable members!
Such preferable 'more modern' arrangements accordingly are thence used to define CCP's consequentially STRICT fault testing criteria. ) at that era of Trainz evolution. This is a much stricter and narrower application of test hurdles and 'interpretation of acceptability', since it applies all cumulative changes up to that version. This is quite a bit different from Content Manager's fault testing which responds to a variation in the listed TBV by applying the appropriate older tests and format interpretations of the TBV standard based on the declared trainz-build. The problem with that is all the CCP variants assume the current minimum TBV tech level, and a minor change of importance only to human operators such changing a name, category-class parameter[note 2] or a description note required upgrading all the data structures for CCP to allow the asset to be reinstalled (i.e. Committed to the Data Base). Hence for normal maintenance of assets, CCP is relatively useless and vexing in that it requires extra time to conform to what it considers necessary, which as noted, are ideals which have no run time effect in the face of old time default behavior and practices! This is not to say CCP was useless. It was an excellent tool for helping new content taking advantage of newer capabilities utilize and get the correct syntax for unfamiliar data combinations or names. Again, as noted, these are generally datum tags and values controlling functionality not achievable in a older data model, which is why they were added! So CCP quickly devolved into a hard-core data creation tool with minimal usage to average Trainzers.
The truth is, this combined treatment is probably N3V Games biggest mistake. For insufficient and inexplicable reasons, the programmers decided to force-feed what amounts to cosmetic and unimportant 'style changes' that could have been handled by a translation process on the user community and burden the content creators with a need to almost continually evolve a work product shelved, if they kept any raw files at all, years ago. Simpler and better for all would have been to take the routines which accommodate different TBVs mix of tags, placements and defaulted values, to allow perfectly functional digital models to be automatically updated to the standard of the CCP desired as a pre-processing step during asset commitment.
This invalidates absolutely no copyrights, because the creator's original files are intact, they are just being stored into the data base with additional and relatively straightforward minor processing to changed replacements--a compressed .chump file (Now TANE's encrypted .tzarc) is created by historical methods no matter what, and the original non-updated and copyright original is retained as a backup! Simple, and efficient—and a non-burden to the user community. The version creep caused by requiring all uploaded content to pass current TBV (Not just a NECESSARY TBV level required by its own use of capabilities, new tags and their values) muster has stifled upgrading of the DLS, or of eliminating missing dependencies within its library of assets. N3V and Auran management and ownership ought be ashamed.
- ↑ Consider that a computer operates hundreds of thousands time faster than human recognition and thought. The N3V method used required thousands of users to fix such things 'deliberately broken by programmer's choices whereas the data model changes under discussion follow specific explicit types of alterations—alterations the Run-Time GUI software APPLIES SUCCESSFULLY every time an older asset is read-in to the data matrix. Suppose instead each Kinds had a translation routine for each TBV level of interest... a V1.3 asset then could and should have automatically been upgraded when the newest TBV introduced 'future-necessary' change, meaning some niche flexibility or less confusable parametric—historically handled by a given default. Couldn't the auto-updated data structure just install said default in the rendered text processing of input to CM and thence to save data base? Instead, the programmers chose to have the problem they created locally by each of the thousands of users for thousands of assets!
- ↑ Category-era, Category-class, Category-era, and category-keywords are all decision criteria, not interpretable by software, but for display of grouping classes to us humans. Irregardless of their lack of utility, some CM/CCP versions will complain of one or the other being missing! Other such formerly legal tags now create the opposite issue— their continued use and definition create a fault message in some higher specified TBV! (e.g. origin, region, type, thumbnail [! Not Thumbnails]... or other tags replaced by a confusedly nearly-the-same-name (now inside a container) or just discarded in the laziness of N3V's programmer-dictatorship.)
