Multiple issues exist with WTC files, versioning, and the Studio
s
sadf htrhr
started a topic
over 6 years ago
While working with the Wikitude StudioManager and StudioEditor, we have noticed a number of serious bugs (mainly in the generation of WTC files) that caused us a number of issues. Fortunately, it's not difficult to work around these issues when they are known, but they should definitely be resolved to prevent confusion in the future.
Issue 1
The WTC file that you get from this button:
And the WTC file contained in the JS Experience ZIP obtained from here:
Are completely different. From our investigation, it seems like the WTC file exported from the StudioEditor only contains augmented targets, while the WTC file from the StudioManager contains all targets. This behavior is understandable, but seemingly undocumented, and when combined with the following issues causes a number of problems.
Issue 2
The version of the WTC file that you export via the StudioManager doesn't seem to correlate with the correct version of the Wikitude SDK, or at the very least do not correlate as one would expect. If you export for Wikitude SDK 6.0-6.1, you get a link to a file at wtc/5.0/tracker.wtc. All versions above 4.0 provide a link to wtc/4.1/tracker.wtc, while 4.0 and 3.x provide the expected URL.
Issue 3
The URLs provided by the StudioManager (and also in the email that is sent when you export) and the URLs included in the project.js of the JS Experience ZIP as remote versions of the WTC files are different. The StudioManager link is formatted thusly:
Note the presence of the /studio, which means that there are two different resource identifiers to what one would expect are the same file. It's possible the server resolves these differences to the same file, but other issues indicate this may not be the case.
Issue 4
All 111 copies version of the remote WTC URL in project.js point to the 4.1 version of the file. For example:
If 5.0 is the most recent version of the SDK to have a specified format of WTC file, as issue 2 seems to suggest, the URL should point to the 5.0 version of the WTC file for version 5.1 of the SDK. If you were to use the 5.1 version of the SDK, the app would use the WTC file for version 4.1, which is a problem when combined with the next issue.
Issue 5
WTC files don't update in unison. If you export for SDK version 6.1 the WTC file at the /wtc/5.0/tracker.wtc URL will update, but the WTC file at /wtc/4.1/tracker.wtc will not. Since project.js always looks for the file at the 4.1 URL, this has the effect of never updating the WTC file for your app, when combined with issue 7.
Issue 6
WTC files update sporadically. As mentioned above, the WTC file for the version being exported will update. However, if you open a target in the StudioEditor, the WTC file at /wtc/4.1/tracker.wtc will update to add only that target. Combined with issue 7, this has the effect of your app only "seeing" the targets that have ever been opened in the StudioEditor.
Issue 7
The logic in the method getBestMatchingWtcFile in tools.js never selects version 5.0 of the WTC file. When the major version is 5 or 6, it will never go lower than version 5.1. This value is then used to determine which version of the WTC file to pull from project.js; however, as mentioned in issue 4, the remote URL will always be pointing to a WTC file from version 4.1, meaning that if you use version 5 or 6 of the SDK, you will always be using the wrong version of the WTC file! In fact, the only values in project.js that specify the local WTC file are for version 4.1 or 5.0, which are never used. In effect, the only version of the WTC file that ever gets used is the one at /studio/wtc/4.1/tracker.wtc, making it impossible to specify that the app should use the local file without modifying the provided Javascript.
Issue 8
There's also no fallback to use the local file when a device has no connection. This makes all apps using the Wikitude JS Experience broken when a device is offline.
Each of these issues alone is rather minor, however, when combined, they make the Wikitude SDK behave in a very unpredictable manner. We were adding multiple targets to our project in the StudioManager but the app was acting like it couldn't see them, even when we made sure to add the StudioManager version of the WTC file (as opposed to the StudioEditor version, which is quite different) to the JS Experience ZIP file, because Wikitude never tries to use the local file.
Please resolve these issues as soon as possible. We've found workarounds for each one, but it requires modifications that have slowed development substantially. I believe each of these issues are trivial to resolve and would improve quality of life for users of your SDK.
I thank you in advance for your consideration and effort in resolving these issues in a timely manner.
sadf htrhr
While working with the Wikitude StudioManager and StudioEditor, we have noticed a number of serious bugs (mainly in the generation of WTC files) that caused us a number of issues. Fortunately, it's not difficult to work around these issues when they are known, but they should definitely be resolved to prevent confusion in the future.
Issue 1
The WTC file that you get from this button:
And the WTC file contained in the JS Experience ZIP obtained from here:
Are completely different. From our investigation, it seems like the WTC file exported from the StudioEditor only contains augmented targets, while the WTC file from the StudioManager contains all targets. This behavior is understandable, but seemingly undocumented, and when combined with the following issues causes a number of problems.
Issue 2
The version of the WTC file that you export via the StudioManager doesn't seem to correlate with the correct version of the Wikitude SDK, or at the very least do not correlate as one would expect. If you export for Wikitude SDK 6.0-6.1, you get a link to a file at wtc/5.0/tracker.wtc. All versions above 4.0 provide a link to wtc/4.1/tracker.wtc, while 4.0 and 3.x provide the expected URL.
Issue 3
The URLs provided by the StudioManager (and also in the email that is sent when you export) and the URLs included in the project.js of the JS Experience ZIP as remote versions of the WTC files are different. The StudioManager link is formatted thusly:
https://s3-eu-west-1.amazonaws.com/target-manager-live/.../wtc/4.1/tracker.wtc
While project.js will have your app looking for the following file:
https://s3-eu-west-1.amazonaws.com/target-manager-live/.../studio/wtc/4.1/tracker.wtc
Note the presence of the /studio, which means that there are two different resource identifiers to what one would expect are the same file. It's possible the server resolves these differences to the same file, but other issues indicate this may not be the case.
Issue 4
All 111 copies version of the remote WTC URL in project.js point to the 4.1 version of the file. For example:
{ "url": "https://s3-eu-west-1.amazonaws.com/target-manager-live/.../studio/wtc/4.1/tracker.wtc", "nrOfTargets": 11, "version": "5.1", "creDat": 1499879070025 }If 5.0 is the most recent version of the SDK to have a specified format of WTC file, as issue 2 seems to suggest, the URL should point to the 5.0 version of the WTC file for version 5.1 of the SDK. If you were to use the 5.1 version of the SDK, the app would use the WTC file for version 4.1, which is a problem when combined with the next issue.
Issue 5
WTC files don't update in unison. If you export for SDK version 6.1 the WTC file at the /wtc/5.0/tracker.wtc URL will update, but the WTC file at /wtc/4.1/tracker.wtc will not. Since project.js always looks for the file at the 4.1 URL, this has the effect of never updating the WTC file for your app, when combined with issue 7.
Issue 6
WTC files update sporadically. As mentioned above, the WTC file for the version being exported will update. However, if you open a target in the StudioEditor, the WTC file at /wtc/4.1/tracker.wtc will update to add only that target. Combined with issue 7, this has the effect of your app only "seeing" the targets that have ever been opened in the StudioEditor.
Issue 7
The logic in the method getBestMatchingWtcFile in tools.js never selects version 5.0 of the WTC file. When the major version is 5 or 6, it will never go lower than version 5.1. This value is then used to determine which version of the WTC file to pull from project.js; however, as mentioned in issue 4, the remote URL will always be pointing to a WTC file from version 4.1, meaning that if you use version 5 or 6 of the SDK, you will always be using the wrong version of the WTC file! In fact, the only values in project.js that specify the local WTC file are for version 4.1 or 5.0, which are never used. In effect, the only version of the WTC file that ever gets used is the one at /studio/wtc/4.1/tracker.wtc, making it impossible to specify that the app should use the local file without modifying the provided Javascript.
Issue 8
There's also no fallback to use the local file when a device has no connection. This makes all apps using the Wikitude JS Experience broken when a device is offline.
Each of these issues alone is rather minor, however, when combined, they make the Wikitude SDK behave in a very unpredictable manner. We were adding multiple targets to our project in the StudioManager but the app was acting like it couldn't see them, even when we made sure to add the StudioManager version of the WTC file (as opposed to the StudioEditor version, which is quite different) to the JS Experience ZIP file, because Wikitude never tries to use the local file.
Please resolve these issues as soon as possible. We've found workarounds for each one, but it requires modifications that have slowed development substantially. I believe each of these issues are trivial to resolve and would improve quality of life for users of your SDK.
I thank you in advance for your consideration and effort in resolving these issues in a timely manner.