PDA

View Full Version : Track preview mesh 'default.im' is missing



rumour3
June 6th, 2015, 03:19 PM
When a user downloads a route that is otherwise compatible with TANE, but relies on an asset which displays this error, the asset will not be visible because it is faulty. If my understanding is correct, and that this error relates solely to the lack of a mesh for the preview window in surveyor, it seems a bit harsh to prevent the asset from showing at all in Driver. Users who aren't interested in creating routes will be hit with an error that they don't know how to fix, thus potentially hurting the overall user experience. Just a thought but might it be worth considering two categories of error- normal errors, that are fatal for content with major performance issues, and 'surveyor-only' errors, that prevent faulty content from being used in routes where the content doesn't already exist. Thoughts anyone?

R3

clam1952
June 6th, 2015, 04:18 PM
Thinking about it, isn't this mainly related to old stuff without a mesh table? I can't remember exactly but think just renaming the im to default and amending the config solved it without adding a mesh table, which I think also solves it. Does seem a bit of overkill on the error side.

Really must make notes when I fix things!

WindWalkr
June 6th, 2015, 08:22 PM
It's an open question exactly how we should display various types of failure.

The biggest problem is that we don't want "average end users" trying to "fix" things, because it often causes more headaches than it solves. To some extent that can be solved by cleaning up the DLS, but when the user is carrying content across from an older local install, or from some third-party site, there's not much we can do about it directly.

As you say, one option would be to change certain errors into warnings. This is a good idea in that scenario, but it also has some negative sides:

* The original content creator will be much less inclined to fix the problem. The point of errors is to say "you're doing this the wrong way."
* The DLS either rejects the content on upload despite it having "no errors", which is probably bad, or it accepts the content in the faulty state, which is possibly worse.
* The content is not flagged for cleanup, and so never gets fixed.
* The content doesn't show up properly in surveyor listings, which (we assume) leads people to blame N3V. Sure, the content creators know what's going on, but "average end users" just see a game bug.

I'm open to suggestions.

chris

BuilderBob
June 6th, 2015, 09:03 PM
It's an open question exactly how we should display various types of failure.
...
I'm open to suggestions.

chris

There should be a new category for Content Manager of

"Caution - this asset is not acceptable for uploading to the DLS. This asset will work in game in its current state, but you will not be able to upload it to the DLS until this problem is fixed."

A lot of performance-based errors might fall into this category.

This means that the user can either ignore the warning or fix it - their choice - but content creators know before they attempt the upload that it's going to fail because of the stricter standards required for new content on the DLS.

Enforcing enhanced standards for DLS uploading is important in improving the quality and reliability of the assets. But there is no need to apply that same high level to the user moving older assets to their newer versions. They make the decisions about the performance or features they lose as a result, provided they get the warning in CM.

But you can't simply relax the testing for CM compared to DLS - content creators need to know before they attempt the upload what is acceptable and what's not. A new category gives content creators the guidance they need, and also alerts users to the fact that their imported content is not up to current standard, but without forcing them to make fixes they might not be comfortable with.

WindWalkr
June 6th, 2015, 09:26 PM
Yeah, I've considered that one, and it does have merits. The most obvious downside there is that we then end up with content which is acceptable in-game but can't be pushed to the DLS. For older content, we don't really care about that, but if we "encourage" that for new content that could become problematic for us- we'd be undermining the effectiveness of the DLS as a central repository for Trainz content.


Another option is one that we discussed on this forum a few days back- some mechanism of tagging a small amount of local content as "in development" and suppressing some of the restrictions on that content. This fixes the problems on the development side, but doesn't help end users.

Building on that, I guess we could do something like this:

* A content creator can flag a certain amount of locally installed content as "in development", but it must have a trainz-build number that is up-to-date (ie. so that they're actually seeing errors rather than warnings or complete suppression of problems.)

* Ensure that any errors which commonly affect end users, and which probably don't hurt the in-game experience too badly, are treated as warnings for older trainz-build numbers. (Meaning that they're less likely to effect end users, but that people using the above mechanism will see them as errors.)

* Disable this error suppression for your own content, and for DLS uploads.


Thoughts on this? There are still ways that people can end-run the system, for example by using an older trainz-build number and somebody else's UserID. Obviously we can't make everything bullet proof and shouldn't try, but I wan't to avoid things which would encourage people to do stupid workarounds.

chris

Kevin16c
June 6th, 2015, 10:15 PM
Building on the error suppression idea, would it be possible to add a new tag to the config file such as this:



developmental-asset X


Where x is either a 0 or 1 with 0 being false and 1 being true?

Just a couple suggestions:


When the tag is set to 1 (true) certain errors are suppressed partially.

They would still be visible at all times but would be colored orange/brown or the likes there-of and would not trigger a faulty status.


When the tag is set to 1 (true) exporting to cdp is disabled.
When the tag is present and set to 1 (true) dls uploads for the asset are disabled.

Either provide an alert or a marker to tell the user the tag must be set to 0 (false) or removed entirely.


When the tag is present and set to 1 (true) content folder importing of the asset is disabled.

Again provide and alert or message to tell the user the tag must be set to 0 (false) or removed entirely.
Note that this suggestion is based on the assumption that the folder importing parses the contents of config file prior to actually adding the asset to the database.





Of course this is easier said than done :D

WindWalkr
June 6th, 2015, 10:30 PM
Building on the error suppression idea, would it be possible to add a new tag to the config file such as this

Yeah, that's basically what we were talking about. Probably controlled via the UI rather than the config file, and limited to some number of assets (to prevent end-users simply blanket-activating it for every asset, and then wondering why nothing works properly.)



When the tag is set to 1 (true) exporting to cdp is disabled.
Not a bad idea, but doesn't really prevent distribution of the content.



When the tag is present and set to 1 (true) content folder importing of the asset is disabled.

This is an interesting variant, but difficult to enforce and would probably just end up with end users making a painful end-run around the system (remove the tag, import, re-add the tag.)

chris

rumour3
June 6th, 2015, 11:01 PM
I like the idea of a tag for development assets.

My thoughts with the original suggestion are that errors can still be errors, but could perhaps be categorised in some way- 'performance' and 'user interface' spring to mind, and possibly others.

I understand that you don't want people fixing assets. Personally speaking, I never fix local copies of other people's assets, because it's then hard for me to keep track of what I've done and I wouldn't be able to guarantee that a route will work as intended if I ever get round to uploading it. Route projects often span months, or years, and Trainz versions. It is incredibly hard for creators when a loved asset suddenly stops working, because the route creator usually isn't in a position to fix it. Replacement is often impossible.

I can see that badly performing assets are obviously the reason behind more rigorous checking, but breaking assets already in widespread use ought to be done with extreme caution.

R3

Kevin16c
June 6th, 2015, 11:11 PM
Yeah, that's basically what we were talking about. Probably controlled via the UI rather than the config file, and limited to some number of assets (to prevent end-users simply blanket-activating it for every asset, and then wondering why nothing works properly.)

Not a bad idea, but doesn't really prevent distribution of the content.

This is an interesting variant, but difficult to enforce and would probably just end up with end users making a painful end-run around the system (remove the tag, import, re-add the tag.)

chris

Perhaps it would be possible to limit the use of the asset to the original content creator himself through the use of author kuid id comparisons. In other words if your author kuid id doesnt match then the tag will not work. Combining all of the suggestions within my post above and this one should force most content creators to fix their asset(s) before it/they can be re-distributed but still allow them to use their own content locally. Of course you would still want to limit the number of assets that can have this flag set to true at any given time. I would propose a cap at 20 - 30 assets that can have this tag at any-given time. (allows for 3 or 4 items of stock or locomotives with their dependencies to be flagged at any given time.)

EDIT: To try and explain further:



if(account_author_id==asset_author_id)
{
developmental-asset-tag_allowed=True;

}
else
{
developmental-asset-tag_allowed=False;
//Insert additional code to alert the end-user and trigger error message
}

Pencil42
June 6th, 2015, 11:24 PM
* Ensure that any errors which commonly affect end users, and which probably don't hurt the in-game experience too badly, are treated as warnings for older trainz-build numbers. (Meaning that they're less likely to effect end users, but that people using the above mechanism will see them as errors.)

* Disable this error suppression for your own content, and for DLS uploads.


I like this idea - it shows me what I need to fix (and gives me incentive to do so by flagging it as faulty on my machine), and I'm not surprised by errors when I try to upload to the DLS. Meanwhile, stuff 'in the field' doesn't become broken for those using it.

As for suppressing errors; I won't offer suggestions on how to do this 'under the hood', but maybe we could right-click on one or more of our assets and 'suppress errors for 5 days'. Assets with suppressed errors get a special icon indicating this state (maybe yellow or orange text?). 'Show errors' will still show all the errors with nothing suppressed.

Just a thought?
Curtis

andi06
June 7th, 2015, 06:19 AM
I would favour the dev-tag asset idea, perhaps

1. Dev-tag flagged assets can't be uploaded obviously
2. Asset userid must match installation userid otherwise trainz produces an error box on loading a map containing the asset (Asset kuid:*** in development: enable for this session only?) this would force the average user to tick a box every time which should be irritating enough to discourage its use without rendering it totally impossible to load the asset to help another creator out.
3. To work around this the user would have to either:
- a: remove the dev-tag in which case full validation would kick in.
- b: give it their own kuid in which case they probably know what they are doing anyway.

As for the effect of the tag itself maybe all non-fatal errors become warnings and all warnings are displayed?

pcas1986
June 7th, 2015, 08:02 AM
Since T:ANE now flags LOD issues as errors, this is the one that really concerns me. I like to look at my assets in game before getting into full scale LOD implementation. Without this I would have to implement some boxy lower LODs to get around the errors. I don't want to have to use build 3.7 or lower.

Showing errors as warnings, perhaps with some caveat or indicator, is still very useful. And I agree with using the developer's userid as a qualification. Ditto for prevention of uploading to the DLS.

It would be useful to have such dependencies for a route or session show some special indicator in CM.

I think this is definitely a case where a test/beta version of T:ANE should be given limited release to those who will test it for these conditions.

clam1952
June 7th, 2015, 08:50 AM
Likewise I load the full model less lod to test before actually starting on the lod side of things, that can't be done in T:ANE so currently has to be done in TS12, not a good idea as the visual appearance can be different, or cobble up some dummy lods which in view of the requirement for a 20% reduction starts making things over complicated unless you just go for the one low lod mesh as a box.
I much prefer to concentrate on one bit at a time get that right before moving onto the next one.
Ideally we should be able to test the basic model plus animation and attachments if required is all as it should be before having to implement any lod.

A dev-tag blocked from uploading and possibly blocked from creating a cdp, would probably be the easiest to implement without getting over complicated, don't want to discourage people from creating stuff by using codes and id's and suchlike, needs a KISS approach IMO.
one tag won't be so much of an issue to most.
I say cdp as I can see this maybe being used as a loophole on third party sites to get round the validations.

whitepass
June 7th, 2015, 11:37 AM
Could you have a check box in CM to suppress all errors for that KUID in game but show errors and warnings?

BuilderBob
June 7th, 2015, 05:03 PM
A tag does not solve the original problem :
"... this error relates solely to the lack of a mesh for the preview window in surveyor, it seems a bit harsh to prevent the asset from showing at all in Driver. Users who aren't interested in creating routes will be hit with an error that they don't know how to fix, thus potentially hurting the overall user experience."

Users who don't know how to create a default im, or other similar simple fixes, won't know how to add a developer tag to get the asset working for them.

Even if the asset is tagged to ignore errors in game there still has to be a distinction made in CM between fatal errors (the asset cannot be used in game as it will crash) and non-fatal errors that can be allowed if the developer tag is set. If that distinction is made in CM then all the developer tag does is change the display status of some errors, so that there is a distinction between fatal and non-fatal errors. I can't see any reason why that should not be the default for CM - no need for a tag to turn the feature on.

Any restriction on importing/exporting 'faulty' assets discourages testing in different versions.

The point about being able to test partly completed assets is well made. Thumbnails is a simple example - why should there be a need to create a dummy first up, when the alternative is to simply leave the whole container out until a decent rendering is available and the asset is ready to upload.

clam1952
June 7th, 2015, 06:28 PM
So.... enable the asset for existing routes that use the item but maybe block any new routes using it by stopping it being listed in surveyor? would that fit with the permit-listing tag? as in 1 or 0, So excluding a physical tag entry, maybe a way of automatically applying the permit-listing 0 to an asset without a preview mesh without actually changing the config or making it easy for fiddlers to circumvent?

BuilderBob
June 8th, 2015, 04:50 PM
As a development of the previous concept, why not go a little bit left field.

1. For CM, change the errors to warnings wherever the error doesn't actually stop the asset being used in game. The warnings might be numbered for importance, or perhaps flagged with a warning type - Performance, Appearance, Functionality etc.

2. Provide a separate 'asset validation' utility that
matches the current DLS upload validation rules
writes a log file, in addition to a display
is updated promptly when DLS upload rules change
includes in the log file the statistics that some rules are based on (# of triangles, textures per chunk, etc)

This assumes that the facility to execute an external program from CM is reinstated.