Repair my content or you may lose it!?

I would also like to see something along the lines of what Linda is talking about. Like you, Linda, I'm not sure of the best way and I can see potential problems.

I'm not a designer and therefore cannot speak for that community. However, I do find it frustrating to come across an otherwise excellent route (or any other asset) which has a lot of 'obscure' missing dependencies. By that, I mean ones that are impossible to find, no matter how much 'googling' and forum searching you do.

Some designers do this very well, but wouldn't it be possible to ensure that when an asset is uploaded, the designer has to quality check it and provide links, or at the very least an indicator of payware or not, for every non-DLS dependency, before it is put on the DLS. As a designer, if you can't find the missing assets, how would you expect anyone else to find them? Taking things to a logical conclusion, why have any asset on the DLS which only the original creator can use properly? Of course, I can see the downside to this, some designers will just stop uploading to the DLS because of the extra time required to do this. As I said, I don't have all the answers but a better level of control is required so more people can better enjoy our hobby - not just the long time Trainz experts.

Getting back to the main topic of this thread (although, I think the above is relevant to it), I'm very pleased to hear that an attempt is being made to correct the broken assets on the DLS. If the current problems have been created by a lack of control in the past, let's hope that this desire to introduce a level of control will succeed - even if it is a little bit late.

Regards, Paul
 
if you can't find the missing assets, how would you expect anyone else to find them? Taking things to a logical conclusion, why have any asset on the DLS which only the original creator can use properly?

Yes, this is exactly right. Not an easy thing to solve, but keep the ideas coming :)


Shortline2 said:
As CM(P) do list things not on the DLS, would it be possible to add in a sort of form where the uploader could put in where the various things not on the DLS came from?

One difficulty with that is that websites come and go, so what might be correct at the time of creation may not be valid later. If we were to adopt a 'registry' of content, it would need to be more dynamic.


kind regards,


chris
 
I think Sparky may (note may) have some good points, but I think Sparky could have toned down his posts.

Hi,

In regards to uploads needing dependencies not on the DLS.

As CM(P) do list things not on the DLS, would it be possible to add in a sort of form where the uploader could put in where the various things not on the DLS came from?
Why not do what Train-Sim dot com does, and only allow items that have a readme file in, that include the links from non-download station. But then again, the links may change.
 
In addition to Terry's comments, it's worth me pointing out that we expect 99% of the errors to be a five-minute fix. We're not asking people to make new models or textures, so there's typically no reason why it would take a long time to fix the items.

Of course there will always be exceptions, so as Terry says, if you have a legitimate reason why you might need additional time then don't hesitate to contact us.

kind regards,

chris

For UK items if you are going to open them up at all then its worthwhile changing the engine specs to stovepipes. Zec has a thread about this and it is highly desirable.

There is also an opportunity to clean up the scripts and couplings side of things. If the coupling and the vacuum pipe were exported together you could have a single mesh that was either coupled or uncoupled. Set it up so it works on a.couple0 and a.couple1 and you've halved the extra load for ACS couplings. Not only that but you could retro fit wagons that don't have the attachment points for couple0 etc. You could drop the lod on the couplings as well for further performance gains. Red lamp set up on couple0 as well? There are some permutations here including buffers but not that many.

I know my TRS2004 scripts clash with certain other scripts so it also makes sense to switch the scripts, especially for blue star rolling stock. I'm not aware of an ACS script that just does couplings and the lamp. The TC3 ones switch textures as well. An efficient standard script should also have a performance impact.

I am aware that N3V isn't especially sensitive to UK requirements, it might be nice to have a UK area in the forum for example but if you are going to open things up why not do it properly.

The amount of creation effort isn't that much but the pay off in performance gain and realism is there.

Thanks John
 
There is also an opportunity to clean up the scripts and couplings side of things. If the coupling and the vacuum pipe were exported together you could have a single mesh that was either coupled or uncoupled. Set it up so it works on a.couple0 and a.couple1 and you've halved the extra load for ACS couplings.
No you haven't because it won't work properly. If you couple a fitted wagon to a non-fitted one then the vac hose shouldn't deploy.

Paul
 
...

The amount of creation effort isn't that much but the pay off in performance gain and realism is there.

Thanks John

Most of what you discuss there requires the original source for the mesh files, and I don't think that really falls into the same realm of what N3V are attempting to do (which is, remove the number of broken items on the DLS), it especially isn't possible in cases where the original author is no longer around in the community (which is the most likely cause for an asset getting 'opened up' for repair by any creator, and thus original meshes and animations cannot be sourced.

While I would agree with the things you stated being important things that could improve trainz, modernising content in such a way is a much different process to repairing broken configurations[1]. Modernising content requires active participation by the original creator, and can be achieved just as well by approaching the creators one-on-one as is possible now - and indeed, something you appear to be doing already.

[1] Although I'm not sure how I feel about the enginespec problem, since a pre-TC3 enginespec on an otherwise error-free locomotive may not move at all in cab mode. Perhaps this is best suited by Auran adding code to trainz 201x that displays a warning when encountering a pre-TC3 enginespec on an otherwise error-free engine, something along the lines of 'this locomotive will likely work correctly in DCC mode, but may not drive correctly in Cab mode'. It may even be possible to offer an in-game enginespec replacement option there and then.
 
I'm willing to bet that a lot of us have corrected many of the basic errors and they are sitting on our hard drives and just need uploading under the fixed procedure? I know I have done a fair few.
 
A couple of questions for N3V...

What about older routes containing broken dependencies? After all other content is fixed, do routes which still have broken dependencies stay or go?

What will be the build number of corrected assets? Will it remain as per the original broken asset or will it be upped to 2.6 minimum?

Andy...
 
Most of what you discuss there requires the original source for the mesh files, and I don't think that really falls into the same realm of what N3V are attempting to do (which is, remove the number of broken items on the DLS), it especially isn't possible in cases where the original author is no longer around in the community (which is the most likely cause for an asset getting 'opened up' for repair by any creator, and thus original meshes and animations cannot be sourced.

While I would agree with the things you stated being important things that could improve trainz, modernising content in such a way is a much different process to repairing broken configurations[1]. Modernising content requires active participation by the original creator, and can be achieved just as well by approaching the creators one-on-one as is possible now - and indeed, something you appear to be doing already.

[1] Although I'm not sure how I feel about the enginespec problem, since a pre-TC3 enginespec on an otherwise error-free locomotive may not move at all in cab mode. Perhaps this is best suited by Auran adding code to trainz 201x that displays a warning when encountering a pre-TC3 enginespec on an otherwise error-free engine, something along the lines of 'this locomotive will likely work correctly in DCC mode, but may not drive correctly in Cab mode'. It may even be possible to offer an in-game enginespec replacement option there and then.

Two sides to the engine spec the first is the rolling stock wagon engine specs. See Zec's comments here.

http://forums.auran.com/trainz/showthread.php?t=64139&highlight=stovepipe+enginespec

The second are the TC3 level and above steam engine specs. What we've been doing is putting a TC3 level version number on these. If you are running TRS2004 or TRS2006 just stick with the lower version number that works in these. If you want to use TS2010 then you can use the TC3 version engine specs.

The second is the couplings, these are separate kuids and are just referenced by the config.txt file. The script side is also just a config.txt file change you don't need to get into the mesh, especially if you set them up to use a.couple0 and a.couple1 which most meshes have. It's the separate kuids I'd like changing.

Cheerio John
 
Last edited:
Originally Posted by johnwhelan
There is also an opportunity to clean up the scripts and couplings side of things. If the coupling and the vacuum pipe were exported together you could have a single mesh that was either coupled or uncoupled. Set it up so it works on a.couple0 and a.couple1 and you've halved the extra load for ACS couplings.

No you haven't because it won't work properly. If you couple a fitted wagon to a non-fitted one then the vac hose shouldn't deploy.

Paul

OK so you have three cases, one where the wagon isn't connected, one where it is connected to a fitted one and one where you are connected to a non fitted one. Three alternative meshes. Yes it gets a little more complex with high and low plus vacuum pipes and the different couplings but not impossible to script and there are performance gains to be had.

The majority of the time items will either be all fitted or all non fitted according to the time period being modeled.

In theory with Blender it's fairly easy to bring the different bits together to form the composite mesh with even a single texture. It's a pain getting it right the first time to work on a.couple0 but not impossible.

Cheerio John
 
Can of worms

Here's my 2p/2c/2 whatever micky mouse money you may have.

1. Could the upload process to the DLS be made to check if all items included on a route is on the DLS. If the items are not on the DLS, the uploader could get a message asking for them to (if possible) change the items to DLS replacements. With the amount of stuff on my trainz install, I now don't know what is on the DLS or on a outside site and don't want to have to check before uploading (I would if I knew it was not on the DLS!).
2. Say if I have corrected a faulty asset, would this then be flagged as obsolete if someone else repaired the original and re-uploaded it? If so, most of us old timers would then have to waste time having to re-download stuff which we have already repaired. Could the CMP be updated to not flag up obsolete stuff by the user if the item has been repaired by the user (an error check routine)?
3. I take it that people will have so long to repair an item that they claim they will sort out? That should push people to get the job done and not stop someone who can do the job.

Regards,
CaptEngland
 
For UK items if you are going to open them up at all then its worthwhile changing the engine specs to stovepipes.

To be clear about this, we're only looking to fix flagged faulty content at the current time. There are a lot of things that could be done to improve the DLS content, but since we're potentially talking about modifying other people's content this could quickly become a slippery slope.

There are a few ways the the kind of change that you're describing could happen:

* That creators replace the older content with new over time.
* That we, at some point in the future, select to improve certain types of realism in the simulation and programmatically flag (first as a warning, later as faulty) anything which does not meet the necessary realism requirements.
* That we identify some way to make such changes without modifying the content.


I know my TRS2004 scripts clash with certain other scripts so it also makes sense to switch the scripts

If you're talking about your own content, you're free to update this at any time.


I am aware that N3V isn't especially sensitive to UK requirements, it might be nice to have a UK area in the forum for example

We don't currently maintain forum sections for different countries. We DO maintain different language sections for obvious reasons, but that's the limit of it. This has nothing to do with whether we think UK-specific rail operations are important - as you can tell by looking at the content we work with, it's a fairly high priority for us. I will pass your comments on, but I suspect that the status quo will be maintained there.

kind regards,

chris
 
What about older routes containing broken dependencies? After all other content is fixed, do routes which still have broken dependencies stay or go?

By broken, I assume you mean 'missing' since once the content is fixed, none of the DLS dependencies will be faulty?

In which case, we have not determined any plans for dealing with missing DLS content at this time. It's certainly a problem that we're aware of, but we're going to address the faulty content before we look into the missing content problem.


What will be the build number of corrected assets? Will it remain as per the original broken asset or will it be upped to 2.6 minimum?

The normal DLS screening process is in place for repaired content. The content will need to be updated to whatever content format is permitted on the DLS at the time the fix is submitted.

kind regards,

chris
 
1. Could the upload process to the DLS be made to check if all items included on a route is on the DLS. If the items are not on the DLS, the uploader could get a message asking for them to (if possible) change the items to DLS replacements.

This is a difficult question, as some of the "obvious" solutions would discourage the use of payware. We're happy for people to use and create all-freeware routes, but we also want to support our third-party payware groups and banning routes or sessions that use payware may be a little strong.

Certainly, providing an end-user tool which checks a route to see whether any content is missing from the DLS sounds reasonable.


2. Say if I have corrected a faulty asset, would this then be flagged as obsolete if someone else repaired the original and re-uploaded it?

Yes.


If so, most of us old timers would then have to waste time having to re-download stuff which we have already repaired. Could the CMP be updated to not flag up obsolete stuff by the user if the item has been repaired by the user (an error check routine)?

The problem here is that if you've repaired these items locally, then the end result may differ from the officially-repaired items. In many cases this may not matter, but in some cases it could cause serious compatibility issues. Our end-goal is to ensure that the content is identical on everybody's machines, and while this is not going to be a rapid process, we don't intend to take steps which would compromise the end goal.


3. I take it that people will have so long to repair an item that they claim they will sort out? That should push people to get the job done and not stop someone who can do the job.

We will certainly keep any eye on the process to make sure that things continue to move forward smoothly. There is a limit on how many items you can reserve for repair, so it's not possible for somebody to block the whole process by grabbing everything then doing nothing with it.

kind regards,

chris
 
What about my suggestion on the previous page? Would that be one idea to put forward?

Regarding the readme files? I answered that one above- the concern with that approach would be that the links would often go out of date making the approach a lot less effective than we would desire.

That doesn't preclude some kind of registry for non-DLS assets, but having each asset maintain its own registry of dependencies would be difficult to maintain and prone to becoming outdated.

kind regards,

chris
 
Quote:
I know my TRS2004 scripts clash with certain other scripts so it also makes sense to switch the scripts
If you're talking about your own content, you're free to update this at any time.

kind regards,

chris

The issue was identify by a third party. When some of my rolling stock was placed on a layout with other rolling stock TRS2004 crashed with a script error. Interestingly enough if you replaced my rolling stock with some of Paul Hobbs's rolling stock you got exactly the same result. Remove the other rolling stock items and no crashes. It appeared that TRS2004 scripts can interact with each other under some circumstances.

Having been a professional programmer for a large number of years I know trying to track an intermittent fault can be difficult and in the case of TRS2004 scripting trying to test every combination would be an enormous task. For that reason I tend to recycle scripts and use the minimum number of different scripts to reduce the variation and possible conflicts.

The availability of a couple of well written "standard" basic scripts could enhance the reliability of Trainz.

Cheerio John
 
Why not have a route that has missing items, have them show a "default item" like a balloon where they are on the map, or some garish texture so you can see whats missing.

If its nothing major you can just delete the missing content.

Cheers

Lots
 
Why not have a route that has missing items, have them show a "default item" like a balloon where they are on the map, or some garish texture so you can see whats missing.

If its nothing major you can just delete the missing content.

Cheers

Lots


If we're talking about suggestions for improving in-game handling of 'missing content' lets go a couple of steps further:

1) Have a dialog box that lists all missing content, and a way within that dialog box to replace that content with other content, the 'replace assets' dialog in ts10 is half-way there already...

2) Show on the map, as you suggest, locations of missing content when in surveyor

3) As mentioned elsewhere in this thread, a repository of information on non-DLS content - kuid mapping to type of item, a brief description, URL and a list of alternate assets that provide a similar look and feel. This list of alternates would get around the problem of sites going down and assets being 'lost to time'. Better still is if this repository is user-editable like a wiki (although limit it to people with a planet auran account, to prevent abuse).

Coupling all 3 of those together, it should be possible to look up the missing items in surveyor, see an item, click on 'visit url' and have the in-game browser window try to open the url. If the URL doesn't work, you can then fall back on automatically replacing with a DLS asset that is either installed, or have it installed automatically and replace the missing asset Since the repository would be user driven, the ongoing work by Auran should be nothing other than a low-level administrative duty (handling occasional abuse of the repository and reverting edits). The amount of work required to implement the system would be surprisingly small since a lot of the ground work is already done - in-game browser, search replace functionality in surveyor, ability to access CM functions from in game (as the current 'updated items' feature uses).

The most work to implement this system would be in writing the wiki-like asset repository, But it isn't as complex as it might seem, and should probably take no more than a couple of weeks for any seasoned web developer.

Such a system would make downloading routes much much more palatable for the less technically inclined users that aren't willing/able to spend large chunks of time searching using google-fu to find missing assets.

Edit To add:

Also, I intended to point out that such a system, with the ability to mark assets as 'suitable replacements' for missing assets would also encourage active asset creators to fill in the gaps left by assets created by people that have long since left the community and whose assets aren't available elsewhere anymore. Such encouragement would probably also act as a revitalisation for some older routes that are otherwise excellent additions to the community, barring the assets that are no longer easily available.

IMO, everyone wins.
 
Last edited:
Moin,

I know it´s a bit off topic because the theme are faulty assets and not missing assets, sorry for posting about missing dependencies nevertheless.

We has created a route and session. While finished the project and writing the list for missing kuids, using a fresh installed Trainz with only BuiltIn content, i found out, that the most missing dependencies are still downloadable via FTP on the DLS but in CMP and CM 3 they are flagged as missing:

boj5hp22pxgddi1sw.jpg


I think, that must be fixed in the actual CM first, only when the CM works correct we can speak about really missing content.
All the not in CM(P) displayed assets has´nt errors, so i can´t found a real reason why they not will displayed.

The first step with no download faulty assets from DLS could also be, that they don´t should be listed in CM for available for download when the internal routine on the DLS server have identified they as faulty.
 
Last edited:
Back
Top