My own assets should not be payware.

Why do N3V keep doing this? Adding payware tags to assets that should not have them and cluttering up configs with non-English language tags. :n:

<kuid2:68213:26021:3> Restaurant El Rodeo (in TRS2019).
 
Only thing I can think of is that it's included in a TRS2019 route. I know that N3V have got some payware tags on some items in error from memory so might need to check with them.

Shane
 
Tony said this a few days ago here:

...
3. We have mentioned many times that any freeware that has become payware is not intentionaly, but a byproduct of the update process and will be rectified over time.

I think it is standard practice for any assets included as built-in to be internationalised.
 
Why do N3V keep doing this? ... and cluttering up configs with non-English language tags. :n:

<kuid2:68213:26021:3> Restaurant El Rodeo (in TRS2019).


In the case of the asset mentioned, the "cluttering up" with non-English language tags consists of ...

username-de "Restaurant El Rodeo"
username-fr "Restaurant El Rodeo"
username-pl "Restauracja El Rodeo"

Not exactly sure what your point is here. English is not the only language spoken by Trainz users so why should all information be presented in English only?
 
The point is that N3V don't enforce their own standards by rejecting assets with non-English names in the username field. And they don't replace a non-English name with an English name either.

Yet they feel it's OK to clutter up someone's perfectly "legal" config by adding a bunch of random non-English username tags. If they are willing to do such favours for non-English-speaking clients, then why can't they do their English-speaking clients and creators the favour of enforcing their "username tag = English" rule? Until they do, I will continue to object to this kind of meddling.


As for the false payware issue being an "unintentional by-product of the updating process", it seems to have been like this for many versions of Trainz now. Isn't it about time the flaky "process" was improved so this doesn't happen?


.
 
Last edited:
...

As for the false payware issue being an "unintentional by-product of the updating process", it seems to have been like this for many versions of Trainz now. Isn't it about time the flaky "process" was improved so this doesn't happen?


.

I think they were more interested in getting TRS19 out the door. I'm curious what would happen if you uploaded a new version of one of those assets.
 
That's interesting because I'm sure the CRG cannot overwrite built-in stuff. But then I'm not sure that we have tried. So far I think we have referred them back to N3V to correct.
 
Another unwanted by-product of N3V adding username-xx tags (or other config edits) is that quite often they will bump up the version number. Since they don't ask or inform the creator, the creator is often left unaware an extra version exists, especially if the new version happens to be built into a Trainz product the creator doesn't have. It can lead to difficulties later when uploading updates.


.
 
Last edited:
I think they were more interested in getting TRS19 out the door. I'm curious what would happen if you uploaded a new version of one of those assets.

It obsoletes the builtin or Payware version, tested some time ago on one of my assets that was marked as payware, as it happened a few builds later it had changed from payware to builtin anyway.
 
So, if they are marked as payware, are they downloadable on the DLS?

If they were ever on the DLS, some may be some not, depends if the kuid was up-versioned for the payware or builtin version, however N3V have stated that they will sort out those items marked incorrectly as payware, they already have done some, so it's hardly worth making an issue about it when it's in hand.

If you have it as payware not sure why you'd need to download a copy anyway.
 
Tony said this a few days ago here:

That response is somewhat disingenuous. The original comments were vague and evasive. It was only after much additional prompting that it was eventually conceded that it was a mistake and would be fixed. In November it was quoted as affecting 18 items. I last counted 250. Either the problem is being seriously understated or it is still occurring. The casual commitment to fix it at some indeterminate point in the future needs to be demonstrated by action. Developers putting their content on the DLS give away a significant part of their rights over that material, and N3V has a responsibility to treat those rights respectfully. It is really strange that N3V should not promptly fix a simple problem that has such serious potential to affect the commitment of a large part of the developer community.
 
That response is somewhat disingenuous. The original comments were vague and evasive. It was only after much additional prompting that it was eventually conceded that it was a mistake and would be fixed. In November it was quoted as affecting 18 items. I last counted 250. Either the problem is being seriously understated or it is still occurring. The casual commitment to fix it at some indeterminate point in the future needs to be demonstrated by action. Developers putting their content on the DLS give away a significant part of their rights over that material, and N3V has a responsibility to treat those rights respectfully. It is really strange that N3V should not promptly fix a simple problem that has such serious potential to affect the commitment of a large part of the developer community.

I have exactly same feeling here, at my home, at the opposite side of the earth globe.
 
Back
Top