PDA

View Full Version : Kuid update, obsolete table or new model?



rumour3
January 8th, 2016, 03:29 AM
Not sure if this one for here or the main content creation forum. Quite a few of my old models are built-ins in T:ANE and I'm pretty ashamed of them, compared with my current standards. I've got new versions in various stages of completion and I'd like to progressively update the built-ins, but in some cases I'm doing things differently- for example, my class 31 had various scripted options including a different cab style, headcodes etc. that aren't in the updated version at the moment. AFAIK, most users never fiddle with the options but there will be a few who did so I'd like thoughts on the best route to provide an updated version. At the moment, I'm leaning towards providing new models that obsolete the old ones, rather than Kuid updates. Am I right in thinking that an asset which obsoletes another will automatically replace that asset in any existing sessions? Or should I only obsolete old models if the functionality/scripting of the replacement is exactly the same as the original, and just create new models that are unrelated to the originals in any way?

R3

pcas1986
January 8th, 2016, 03:44 AM
I'm interested in this question as I've been thinking about for months. I have a few assets that require severe surgery for T:ANE and I see the same options as R3.
From earlier posts on the issue I got the impression that those diehards sticking with TS12 will not see these assets as obsolete but I'd like a definitive answer.

There is another forum that might be appropriate but it is private and not visible. Therefore I think this forum is as good as any.

rumour3
January 9th, 2016, 08:46 AM
I guess Chris is busy with SP1- hopefully he's fixing the shadows...;)

R3

clam1952
January 9th, 2016, 09:34 AM
A case of damned if you do damned if you don't.
I have a feeling that the kuid2 system was supposed to replace the obsolete table anyway, may only still work to maintain backwards compatibility, probably need clarification from Chris that it isn't going to vanish at some point!

Kuid2 or obsolete table will have people who won't upgrade or can't upgrade from lower builds loudly complaining that they can't download the original (Read that as probably don't actually know how to) and they have updates they can't use clogging up their content manager. probably the option that causes the least disruption for TS12 and lower is a complete new model.

I used kuid2 to update all of my Trees for TANE, they have a TANE specific tag to stop them affecting smoke! when overhanging track, and then due to complaints had to up-version the originals to replace the updates and upload new versions for TANE, easier than explaining to people how to find old versions on the DLS white pages if pre TS12 SP1 or use download this version in TS12SP1, which incidentally doesn't always work!

WindWalkr
January 9th, 2016, 07:43 PM
There is no real difference between the handling of the obsolete-table and the handling of KUID2 revisions. The pros/cons are as follows:

* KUID2 versioning is more obvious, because you can make assumptions based on a single KUID2 without looking up any config.txt files.
* KUID2 versioning is limited to ~128 versions.
* If you start by using KUID2 versioning and then move to using an obsolete table, there's more chance of user confusion ("why can't i make a v3?")

With either method, the game will use the latest asset version that it has installed whenever it attempts to load an asset. This means that you should not release an update unless it has been confirmed to be compatible:

* It must comply with any script APIs that the older version made public. If the old version was faulty in some externally-visible (but correctable) fashion, the new one should remain faulty in that fashion through the existing APIs and any corrections should be exported through a new API. This ensures that scripts which used your old API continue to behave in the same fashion.
* It must maintain the same dimensions, position, and orientation. This ensures that it fits neatly into the same places in the route/session as the previous version.
* Spline or Train-End attachment points must not be moved, to ensure that splines do not become disconnected and vehicles are not derailed.
* Ideally, no meshes should be removed, renamed, or substantially edited, as this will break reskins.
* Industry queues should not be added, removed, or edited.
* Behaviour should remain close to identical from a user perspective. You may add optional additional behaviour, but it should be opt-in. This ensures that any existing usage will still see the original behaviour.
* These are all just examples; I'm sure you can think of some more. The point is to try not to break anything that already exists.


If you're not willing to abide by these, just make a new asset and leave the original one alone.

chris

pcas1986
January 9th, 2016, 08:24 PM
... The point is to try not to break anything that already exists.


If you're not willing to abide by these, just make a new asset and leave the original one alone.

chris

Thanks for the detailed response. The quote above sums it up pretty well and, given Clam's comments, I'll limit my "repairs" and make them new (T:ANE) assets.

rumour3
January 10th, 2016, 04:01 AM
Thanks Chris. I'll generally keep to all-new models as well. Given how strict the criteria for updating are, shouldn't N3V have a different and more rigorous system in place for checking items that update built-ins, compared with the normal DLS upload? Strikes me that there's a lot of potential here for someone to inadvertently break built-in routes and sessions, if updates aren't subject to some form of enhanced quality control?

R3

WindWalkr
January 10th, 2016, 07:35 AM
shouldn't N3V have a different and more rigorous system in place for checking items that update

Many of these items would be impossible to check automatically, or would be very subject to false positives. For example, how do you prove that a script mimics the behaviour of a different script? How do you prove that a given mesh will fit into the same place in a route as another different mesh? In both cases, you need to apply human judgement to determine what the identifying characteristics of the original item are, and then you need to determine whether the update matches those characteristics. This isn't something that current-day computers can do.



Strikes me that there's a lot of potential here for someone to inadvertently break built-in routes and sessions, if updates aren't subject to some form of enhanced quality control?

Absolutely there is. At the end of the day, if we feel that somebody has broken something important, then we have the capability of stepping in and fixing it; potentially by re-uploading the original version and wiping out the changes. We do have to step in with DLS issues from time to time, but thankfully it's not a regular problem.


Longer term, I've been considering removing automatic obsoletion completely. Doing this solves a large number of problems, and has very little long-term downside. Unfortunately it does have a potential one-off downside that we'd need to consider, as well as a reasonably substantial development cost, so we're not going to seriously consider it until we have time to do a thorough job.

chris