My UK Station Modules - a warning.

ray_whiley

Active member
I have noticed that three of my station modules (KUIDs 275817:1121,1125, and 1133) have recently appeared on the Download Station for TS12. This is without my knowledge and I would like to warn potential users that these are not my work and I have never, in fact, created or uploaded any custom content for a version of Trainz later that TS10. (There is a good reason for this: although I have registered TS12, it will not recognise or accept my KUID for content which I create.)


I have tested these modules in TS12 and find that I can not use them. Burhill Revised shows only a station building, platform lamps and a water tower; Cranleigh Revised has only point levers, footbridge and lamps; Denmead Revised has only a footbridge, lamps, levers and a coal merchants premises. None has any track, platforms etc. although the originals were complete station layouts, without other scenery. (Note that this is in TS12 "straight from the box" and unpatched.)


I must assume that someone has "repaired" these assets which were originally made for TS10. Anyone who downloads them must do so with this warning in mind and realise that any deficiencies can not be blamed on me.


Ray Whiley (Dukes Denver Designs)
 
Ray, I'd raise a ticket on this and complain, obviously yet again whoever fixed them never tested them.
 
Here we go again. Just because the original creator doesn't updated an object can there be a way to validate "repairs" so that the real creator isn't embarrassed when things like this happen? How about forcing the one doing the repair to add a line in the description (or a new update tag) to take responsibility for any changes as well as a change log to list what was changed? If I don't agree or find the changes undesirable, I can at least easily undo them locally.
 
Many thanks for these comments and suggestions. I think the originals would have been OK in TS12 other than for missing dependencies. It is certainly embarrassing when one tries one's best to check for errors before uploading anything - or to correct any errors which are pointed out.

Perhaps whoever "repaired" these modules might like to contribute to this thread?

Ray
 
Here we go again. Another content creator claiming to have a 'policy' about managing their routes but failing to respond to the warning emails about their content being put onto the list.

If you allow it to go to the list it's going to get updated.

FWIW, I just downloaded these three into TS12 and they look just fine. It's not difficult to do a side-by-side comparison of the configs and find out what was actually changed, but my guess is you need to download newer versions of those 'missing' assets.
 
Here we go again. Another content creator claiming to have a 'policy' about managing their routes but failing to respond to the warning emails about their content being put onto the list.

If you allow it to go to the list it's going to get updated.

FWIW, I just downloaded these three into TS12 and they look just fine. It's not difficult to do a side-by-side comparison of the configs and find out what was actually changed, but my guess is you need to download newer versions of those 'missing' assets.

Here we go again.

It is also a well known fact, that some of these "warning emails", are going straight into the recipients email trash, so don't get seen when checking the 'In Box', so probably NOT Rays fault he never saw it.
This has been reported a number of times on these boards, but as usual, it falls on deaf ears with the fanboyz.
 
Last edited:
It is also a well known fact, that some of these "warning emails", are going straight into the recipients email trash, so don't get seen when checking the 'In Box', so probably NOT Rays fault he never saw it.

Emails will only be trashed if the user has set up a rule to trash them. Hardly the sender's fault. If you mean Junk, checking the junk folder before clearing it is the recipient's responsibility. If you mean Spam then he has a whitelist option.

If he's that concerned why not just check the list every now and again?
 
I did receive an email stating that these assets needed to be repaired but as there was no clue as to what needed to be done I was content to leave it to someone else who was more knowledgeable than myself. I had not realised that the original author, kuid and version number would be retained and this is what I am commenting on. I was of course interested to see what changes had been made which was why I downloaded and viewed them in TS12 and was disappointed with the result - hence my warning disclaiming responsibility. If others find these station modules can be used, I am very pleased.

Incidentally, my only "policy" is to allow free use and modification of anything I have created as is clearly stated in my licence - although I do request that I be informed of any modifications.

Ray
 
Last edited:
I did receive an email ... I was content to leave it to someone else who was more knowledgeable than myself. I had not realised that the original author, kuid and version number would be retained and this is what I am commenting on. ...

Ray
Well that certainly puts a different spin on this story. IIRC, the repair process does mention that the original kuid is preserved with a new version.

Still think that adding a change log tag would go a long way to resolving the issue with knowing what was changed and by who.
 
Well that certainly puts a different spin on this story. IIRC, the repair process does mention that the original kuid is preserved with a new version.

Still think that adding a change log tag would go a long way to resolving the issue with knowing what was changed and by who.

Having a change log or the ability to add in the information somewhere in the config.txt even automatically would make tracking down problems a lot easier.

This could be done as a tag or in the descriptions somewhere and looks something like this.

Asset updated by user: Jim_Smith 23/03/16.

If the asset is update by the original author again, then his name will appear above that in the description so keeping with the same example, we would see something like

Asset updated by user: Fuzzy343234 on 05/05/16.
Asset updated by user: Jim_Smith 23/03/16.

This could be by username so we'd see as above, or by user ID instead and or both.

The reason for this is not to shame or admonish the updating user, but to help track who made changes in case they did something incorrectly and they can be contacted again for a repair, and to notify them so they don't make the same error on other assets. A good example of ruined assets are some engine specs that made it up to the DLS in the past. These effectively broke the Alco RS3 locomotives until a new update came out quite some time afterwards. If the person updating the asset to work in TS12 at the time was notified, he could have corrected the mistake by re-uploading the asset again with a new revision much sooner.

Anyway, my thoughts on this.

John
 
Thank you, martinvk and John - I fully agree with your suggestions which would certainly avoid any blame for problems being aimed at the original creator. I certainly expected that at least a new version number would be used for any repaired asset, if not the KUID of the repairer.A tag in the description, as suggested, would make it immediately obvious that the asset had been modified and by whom. And of course anyone modifying and uploading his/her own asset would have to give a new version number - or so I have always understood.

Ray
 
I did receive an email stating that these assets needed to be repaired but as there was no clue as to what needed to be done I was content to leave it to someone else who was more knowledgeable than myself.

Leaving it to someone else is inviting exactly what you are complaining of. If you didn't want to do the repair, offer it to someone who will do it for you so you can check it's done 'properly' before uploading.

But in any case I would suggest you take another look at these routes, because AFAICT they work properly in both TS12 and T:ANE. Of course, it's not possible to know that they are the same as originally submitted because they weren't working previously, but the dependencies match (except for some that got added, which I assume are things like water and region) and as the dependency list is created automatically that must mean everything is still in the route.
 
No, I was content to leave it as you say because I am not able to upload for TS12 as mentioned earlier. However I did expect that at least the version number would change.

I am very pleased to hear that these modules do work in both TS12 and T: ANE and the problem must lie in my computer! But I do feel justified in pointing out that if anyone else found problems, then I was not responsible.

Ray
 
Well, these station modules have been repaired and uploaded by someone without the version number being incremented which makes the asset seem to be my original work. Perhaps that is why I had problems after downloading when others seem to find them OK?

Ray
 
Perhaps that is why I had problems after downloading when others seem to find them OK?

Could be. I have a copy of the list as at June 2015.
Cranleigh revised,<kuid:275817:1121> 3.2
Denmead revised,<kuid:275817:1125> 3.2
Burhill revised,<kuid:275817:1133> 3.2

That means that the current latest versions are the repairs:
Cranleigh revised,<kuid2:275817:1121:1> 3.5
Denmead revised,<kuid2:275817:1125:1> 3.5
Burhill revised,<kuid2:275817:1133:1> 3.5

If you already had these versions on your system then the repaired versions would not have downloaded.
 
No, I do not have these on my system but I realise that the original must have been read as version 0 (zero). So I was mistaken in thinking that the version had not been updated. My apologies.

But I still think that it would be helpful to see immediately that an asset had been repaired by someone other than the original creator.

Ray
 
Last edited:
But I still think that it would be helpful to see immediately that an asset had been repaired by someone other than the original creator.

Repairers are not permitted to make any changes other than the actual repair. If it's not reported as an error it can't be changed.

If you believe the rules should be changed you should take this up with N3V, perhaps through the developer group. There was a suggestion that the process is being reviewed and revamped, but that was quite a few months ago and nothing has happened.
 
Back
Top