Find Object Problem

The name of an object I think has little to do with the kind such as kind scenery versus kind track-object. That should be the case unless a script relies only on the string name, and that wouldn't be a good thing. The script /driver command author should refer to the object kind as well somewhere in the script, or at least define this somewhere in the script on initialization.

One of the problems I have run across when merging in routes is duplicate object names. Yes. I ran into some switches named similarly on two different routes, and I've had issues where signals and switches did not update their numerical sequence when merged in. This caused problems with scripts and driver commands which rely on those relationships, but the scripts were not affected by a named sign along with a station of the same name.

Trackside objects (track marks, triggers, signals, etc) should be separate from scenery objects. This problem, of both appearing in the same search list, was an issue some versions ago but was fixed, and as often happens in software development, it has reappeared in the latest versions. A bug report has been raised and they are "looking into the matter". Hopefully it will be fixed (again!).

Lewiscc65 said:

Ihope we get an update soon. Looks like there is a bigger push on the TS19 betathan there is to getting SP3 corrected. One thing I found out is you cannotmove a route from SP3 beta to the earlier version even though the CM build isstill 4.5. Unlike TS12 the CM build does not reflect the upward build.

Click to expand...

That's odd - my TANE Test Route was created in SP3 and moved into my HF beta, modified and moved back with no apparent issues. One thing I did was open both CMs at the same time, deleted the earlier version in SP3, open the modded one for edit and dropped the editting folder into SP3. No CDP involved.

:B~)