Certain Animation cs file issues fixed with Shape Editor
by Steve Acaster · in Torque 3D Professional · 06/25/2009 (6:16 pm) · 5 replies
I ported my custom stuff over to Beta3, quite a bit has changed on how the player works/spawns/scripts etc. There's a fair few changes but you can spot most of them (singleton not datablock now etc).
Everything was going fine until I found this little "characteristic".
Start up Beta3, load mission, play game, exit mission back to main menu, reload mission = no animations all of a sudden, nothing amiss in the console. It appears that after the first load, the player/object/dts/cs file with the animation sequences in doesn't get a reload. Look in Shape Editor and sure enough, now it has no animations associated with it.
Quit completely and restart Beta3 and animations work on first load. Go into Shape Editor and save the loaded animations, now it has a "onload" function for them in the shapes/players/customplayer.cs. Now it loads them everytime.
So incase anyone else is suddenly baffled by this issue, this is how Beta3 wants things done now.
Also I've noticed that "customplayer" profiles need to be "customplayerdata", or it complains in the console about the lack of "data" in the word. So that's something else to look out for. And you don't need to call the object (customplayerdts) anymore in the shapes/players/customplayer.cs, you can lose the dts (Shape Editor will do it for you).
Hope that vaguely made sense.
Resolved
Everything was going fine until I found this little "characteristic".
Start up Beta3, load mission, play game, exit mission back to main menu, reload mission = no animations all of a sudden, nothing amiss in the console. It appears that after the first load, the player/object/dts/cs file with the animation sequences in doesn't get a reload. Look in Shape Editor and sure enough, now it has no animations associated with it.
Quit completely and restart Beta3 and animations work on first load. Go into Shape Editor and save the loaded animations, now it has a "onload" function for them in the shapes/players/customplayer.cs. Now it loads them everytime.
So incase anyone else is suddenly baffled by this issue, this is how Beta3 wants things done now.
Also I've noticed that "customplayer" profiles need to be "customplayerdata", or it complains in the console about the lack of "data" in the word. So that's something else to look out for. And you don't need to call the object (customplayerdts) anymore in the shapes/players/customplayer.cs, you can lose the dts (Shape Editor will do it for you).
Hope that vaguely made sense.
Resolved
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#2
You've hit the same problem as Jeff reports here. I've posted a workarounds (which you are already using by re-saving the TSShapeConstructor datablock using the Shape Editor) and the actual fix (if you are able to rebuild from source).
Not sure what you mean here?
I was hoping the official docs on this would be up by now, but the main changes to TSShapeConstructor are:
1. It is no longer a datablock. You should use the 'singleton' keyword instead of 'datablock' when declaring these objects.
2. Whenever Torque 3D loads a DTS or DAE file, it looks in the same folder for a script with the same name (eg. ForgeSoldier.cs for ForgeSoldier.dts). This script is executed automatically before the shape is loaded, meaning you can create a script with the TSShapeConstructor definition and put it in the same folder as the DTS/DAE shape and let Torque execute it for you!
3. The TSShapeConstructor::onLoad function is called after the DTS/DAE shape is loaded (but before it is available to any other object like Player or StaticShape), so you can use this method to add/remove nodes or sequences as needed.
06/29/2009 (3:59 pm)
Hi Steve,You've hit the same problem as Jeff reports here. I've posted a workarounds (which you are already using by re-saving the TSShapeConstructor datablock using the Shape Editor) and the actual fix (if you are able to rebuild from source).
Quote:Also I've noticed that "customplayer" profiles need to be "customplayerdata", or it complains in the console about the lack of "data" in the word. So that's something else to look out for.
Not sure what you mean here?
Quote:And you don't need to call the object (customplayerdts) anymore in the shapes/players/customplayer.cs, you can lose the dts (Shape Editor will do it for you).
I was hoping the official docs on this would be up by now, but the main changes to TSShapeConstructor are:
1. It is no longer a datablock. You should use the 'singleton' keyword instead of 'datablock' when declaring these objects.
2. Whenever Torque 3D loads a DTS or DAE file, it looks in the same folder for a script with the same name (eg. ForgeSoldier.cs for ForgeSoldier.dts). This script is executed automatically before the shape is loaded, meaning you can create a script with the TSShapeConstructor definition and put it in the same folder as the DTS/DAE shape and let Torque execute it for you!
3. The TSShapeConstructor::onLoad function is called after the DTS/DAE shape is loaded (but before it is available to any other object like Player or StaticShape), so you can use this method to add/remove nodes or sequences as needed.
#3
In art/datablocks/players/mycustomplayer.cs
This is okay
and this isn't
and gives this console error
It might be hardwired into the code that it's looking for a description that ends in "data", but I didn't see anything in the scripts that says it's required, though obvisouly it is.
Not being a programmer I don't hunt through code though I do read the scripts.
06/29/2009 (4:15 pm)
Quote:Not sure what you mean here?
In art/datablocks/players/mycustomplayer.cs
This is okay
exec("art/shapes/players/mycustomplayer.cs");
datablock PlayerData(mycustomplayerdata : DefaultPlayerData)
{
//stuff
};
//PlayerDatasGroup.add(mycustomplayerdata);
//don't need this anymore if execd properly in init.cs
//I think ....and this isn't
exec("art/shapes/players/mycustomplayer.cs");
datablock PlayerData(mycustomplayer : DefaultPlayerData)
{
//stuff
};
//PlayerDatasGroup.add(mycustomplayer);
//don't need this anymore if execd properly in init.cs
//I think ....and gives this console error
Namespace::unlinkClass - cannot unlink namespace parent linkage for mycustomplayer for TSShapeConstructor. Error: cannot change namespace parent linkage of mycustomplayer from TSShapeConstructor to PlayerData.
It might be hardwired into the code that it's looking for a description that ends in "data", but I didn't see anything in the scripts that says it's required, though obvisouly it is.
Not being a programmer I don't hunt through code though I do read the scripts.
#4
Adding the 'Data' to the end just makes the PlayerData name unique => you could actually use any string you like here. Some common conventions are:
1. For TSShapeConstructor objects, use a camelcase version of the filename (eg. MyCustomPlayerDts for mycustomplayer.dts).
2. For PlayerData datablocks, append 'Data' to the base name (eg. MyCustomPlayerData for mycustomplayer.dts).
But it is entirely up to you.
06/29/2009 (6:50 pm)
I think the problem here is that you have already declared a TSShapeConstructor object called 'mycustomplayer'. You are then trying to declare a PlayerData datablock with the same name.Adding the 'Data' to the end just makes the PlayerData name unique => you could actually use any string you like here. Some common conventions are:
1. For TSShapeConstructor objects, use a camelcase version of the filename (eg. MyCustomPlayerDts for mycustomplayer.dts).
2. For PlayerData datablocks, append 'Data' to the base name (eg. MyCustomPlayerData for mycustomplayer.dts).
But it is entirely up to you.
#5
Originally I figured that having all of the names the same would help linking the playerdata to the model object and it's info, but obviously that just causes it to get confused when it's trying to reference the name of one and 2 different data sets come up.
Stock files use data as the (playerdata) data extension and (playerdts) for the model object extension as a double safety for not confusing the (player). I hadn't tried any other words as extensions, I'd just followed the stock examples, hence why I mistook there to be a reliance on those extensions.
Cheers for the explanation, I usually can find a way for things to work and establish the rules that make them work, but it's always best to understand the whys-and-whats.
06/29/2009 (7:59 pm)
Ah, I see how it works. Originally I figured that having all of the names the same would help linking the playerdata to the model object and it's info, but obviously that just causes it to get confused when it's trying to reference the name of one and 2 different data sets come up.
Stock files use data as the (playerdata) data extension and (playerdts) for the model object extension as a double safety for not confusing the (player). I hadn't tried any other words as extensions, I'd just followed the stock examples, hence why I mistook there to be a reliance on those extensions.
Cheers for the explanation, I usually can find a way for things to work and establish the rules that make them work, but it's always best to understand the whys-and-whats.
Torque 3D Owner Matt Kronyak
RealmSource LLC