Freeware UTLX 23000 gallon tankcar error

I just downloaded the Jointed rail freeware item UTLX 23000 gallon Funnel Flow tankcar, but the CM indicated an error and this turned upError: Script class does not match asset kind (vehicle).) Any way to fix this?

Just downloaded this into build 49922, no issues apart from 2 products missing which are on the dls.

Hmm... Try reinstalling. If that fails work with the asset kind until it works with the script class.

It seems after I launched trainz the error just disappeared, don't know how it just fixed itself.

Solution to: Error: Script class does not match asset kind

nicksapp1209 said:

It seems after I launched trainz the error just disappeared, don't know how it just fixed itself.

Click to expand...

Here's how it fixed itself...

Bumping this to document the solution, as this one is sneaky and frustrating.
while
site:http://forums.auran.com "Error: Script class does not match asset kind (vehicle)." makes this the top post.
http://forums.auran.com/trainz/show...oes-not-match-asset-kuid-(trackside)-Problems shows there is a general problem in certain circumstances with scripted assets.

Jcitron, Pcas1986, and I each got varying symptoms based on CM system settings when this occurred for three NG cars I'd adapted in TRS2006 and upgraded and a similar upgraded of a V2.0 Randy Whitepass asset... none of which had the least thing altered in the scripts, et. al. I bundled a zip file of the raw edit files and cdps and Paul Cass never saw the message. John did.

The secret is the system setting for Commit after import--John and I don't auto-commit, Paul did. Note the similar lack of success in that Trackside asset problem the OP had for a time... with J-R assets!

• (J-R, whitepass, narrowgauge and slugsmasher are not content creators likely to allow unfixed errors to occur, so these really do cause puzzlement!)

So the secret is to at least, to commit the asset before accepting that last error is valid...it's not. Committing the asset apparently does a better job of connecting the *.gs to the class and the asset commits without errors. // Frank

the reason is more than likely the way the scripts are handled on these items. they need to compile based on scripts in another asset (a library) and sometimes trainz is unable to update its own cache in time for the compile to take place. this very well may have something to do with auto commit - but i disabled that long time ago to avoid the dreaded validation of assets when it seems that you dont really need to so i cant say for sure. either re-commit the item to cause it to re-validate itself in the script cache, or remove the script cache to force it to re-validate and rebuild the cache. i also dont find it implausible that trainz may continue building the cache and validating at some other point, which would seem to an observer to magically fix itself.

Fabartus said:

...

The secret is the system setting for Commit after import--John and I don't auto-commit, Paul did. Note the similar lack of success in that Trackside asset problem the OP had for a time... with J-R assets!

• ... // Frank

Click to expand...

Hmm, no I don't, and haven't done so for years. What I did was to commit those assets you sent me in TS10 and TS12 and all were clear of errors.

The script validation on commit appears to be rather different from a simple Trainzutil compile which I use as a parser check. I've had some strange errors, particularly when an asset's script is dependent on another, as NFS37 mentioned, but I don't recall that particular error in that context. I've only seen that error when experimenting to see what classes I can use with particular asset KINDs.

Why that error would be output when the kind is traincar and the script class is derived from the Vehicle class seems rather odd. I can only imagine that a compilation error has occurred immediately prior to that and the compiling process has "gone off the track" and is misreporting. That's not unusual for compilers in other programming languages.

Cheers
Paul

Edit: Sorry, I intended Trainzutil compile and not validate.

pcas1986 said:

Hmm, no I don't, and haven't done so for years. What I did was to commit those assets you sent me in TS10 and TS12 and all were clear of errors.

The script validation on commit appears to be rather different from a simple Trainzutil compile which I use as a parser check. I've had some strange errors, particularly when an asset's script is dependent on another, as NFS37 mentioned, but I don't recall that particular error in that context. I've only seen that error when experimenting to see what classes I can use with particular asset KINDs.

Click to expand...

OK, sorry I misunderstood you, We'd been better off with VOI, but you keep those funny hours! In any event, we agree they went away when a commit happened. You got no error validating the asset manually, I kept getting them on TS09 AND two version (levels) of TS12... and I've lost more hair (not to mention time!) than I could afford over those! At least you, Justin, and I agree committing the asset seems one way to verify the validity of the error! If it sticks around, something else is fishy. Nuff said. // F

pcas1986 said:

Why that error would be output when the kind is traincar and the script class is derived from the Vehicle class seems rather odd. I can only imagine that a compilation error has occurred immediately prior to that and the compiling process has "gone off the track" and is misreporting. That's not unusual for compilers in other programming languages.

Cheers
Paul

Edit: Sorry, I intended Trainzutil compile and not validate.

Click to expand...

Not sure when an isolated asset fix would generate a compile error. I can tell you in general, I keep a filter so all the 'work' assets I've selected stay in the main view, normally just less than a screen full. I've learned the hard way to not open more than half-a-dozen at a time of that work list, and proceed progressively through them by author (often the same issues) until they've all been cured and committed. Those, since they were being so stubborn I would occasionally revisit, normally right after successfully fixing and committing something less stubborn. Hence residual compile error state seems unlikely.

Bottom line, it happened, happens, and is a bug of a minor degree that shouldn't happen. Traincar and Class and file were all correct. I suppose I could have something imported in my particular libraries or some holdover in the JA's installed that could cause the condition. I'll try it in my backup 'pristine clean' TS12-SP1 which is factory mint and see if it occurs there too. Later though.Time to get dinner!
Thanks for your input Justine. As usual, you make sense! // Frank

Fabartus said:

....
Not sure when an isolated asset fix would generate a compile error. ....// Frank

Click to expand...

Sorry, I didn't make myself clear. An asset fix that doesn't mess with the script will generally should not raise an error or warning. But when developing scripts you can see lots of them. Or at least I do. :hehe:

Cheers from sunny, but freezing, Canberra.