Delete - ECML King's Cross???

For some perverse reason an obsolete ECML route cannot be deleted. It is marked as obsolete. A different copy shows no issues. So how do I delete the obsolete copy.I am also blocked from changing the config flag. I would also like to delete the working copy since I have no interest in it.

It's probably built-in - these can't normally be deleted via Content Manager anyway.

Shane

shaneturner12 said:

It's probably built-in - these can't normally be deleted via Content Manager anyway.

Click to expand...

It's listed as "Installed, Obsolete, Payware". It ought to be possible to remove these obsolete payware routes by removing the package and doing a database repair. That's if anyone can work out the erratic package numbering scheme.

Indeed - that's the way it would have to be done as it cannot be done through Content Manager.

Shane

EDIT: Just found the relevant list on the Wiki (it may be incomplete though) - http://online.ts2009.com/mediaWiki/index.php/Help:In-game_Downloading

I would imagine that will get sorted out when the proper version of TRS19 get released, deleting them during a Beta will probably just get them appearing for download again.

shaneturner12 said:

Just found the relevant list on the Wiki (it may be incomplete though) - http://online.ts2009.com/mediaWiki/index.php/Help:In-game_Downloading

Click to expand...

It's not just that it's incomplete - the problem is that it doesn't relate package numbers to version numbers. The current list of obsolete installed payware seems to be:
<kuid2:154322:101483:22> ECML Kings Cross - Edinburgh
<kuid2:57230:100074:11> Sebino Lake, Italy (1980s)
<kuid2:69379:100014:13> SnC Carlisle Skipton

These are the result of a change in package numbering for the subsequent version. That table needs to indicate what the current and prior package numbers are. The lack of support for beta testers in managing their systems in order to provide the best possible feedback is an ongoing issue that has been repeatedly ignored.

It is getting confusing as now I've got another Sebino downloading, all these beta updates have crippled my monthly data limit, 30GB used in 9 days, had to drop back to my very slow uncapped ADSL, at 300KB/s its going to take hours.....

I really think N3V should consider just updating the changed bits of packages, not keep re-downloading the whole thing every time there's a small fix to the DLC, if that's what's happening.

clam1952 said:

I would imagine that will get sorted out when the proper version of TRS19 get released, deleting them during a Beta will probably just get them appearing for download again.

Click to expand...

What's the point of beta testing if it's going to get 'sorted out' later on? Isn't a beta supposed to test what the end user will experience? The process should emulate what will eventually happen. If there is going to be a change in package numbers then the process for the beta tester should be the same as that which the final user will experience. Otherwise only a fraction of the work that's being done is actually getting tested.

We should have been told how to set the system back to the equivalent of what the end user would start with. I think that involves removing the package for the old version from the server, removing it from the user's installation, rebuilding the database, adding the new version into the server, confirming that it appears as a download, downloading it, and then testing it.

Many beta testers could have worked this out for themselves if they had simply been advised of what was going to happen. Instead new versions are released without any prior warning and with minimal additional information.

BuilderBob said:

It's not just that it's incomplete - the problem is that it doesn't relate package numbers to version numbers. The current list of obsolete installed payware seems to be:
<kuid2:154322:101483:22> ECML Kings Cross - Edinburgh
<kuid2:57230:100074:11> Sebino Lake, Italy (1980s)
<kuid2:69379:100014:13> SnC Carlisle Skipton

These are the result of a change in package numbering for the subsequent version. That table needs to indicate what the current and prior package numbers are. The lack of support for beta testers in managing their systems in order to provide the best possible feedback is an ongoing issue that has been repeatedly ignored.

Click to expand...

I can agree with you there although it's one that N3V need to sort out.

Shane