2D Blogs: Module System
by Michael Perry · 10/13/2012 (9:45 am) · 38 comments
Torque 2D Blog: Modules
Kickoff
Greetings everyone. It's another 2D blog day! When time allows, someone on the 2D team will post a blog or resource related to Torque 2D and/or iTorque 2D. The majority of the posts will come from myself, but don't be shocked if someone else takes over for me from time to time.It's been a while since my last post. Between raising a kid, spending time with my wife, moving from Vegas to Florida, and generally working like mad on multiple GG projects, I just have not had the time to write a blog during the weekdays. Thankfully, we have family in town and they have all gone out shopping. That leaves me completely alone on a Saturday.
I had two options. I could either play Borderlands 2 as long as possible before they get back, or I could write up a 2D blog. Despite my absolute love for BL2, I figured you all deserve an update on T2D's progress. So here it is, after the discloser of course.
FULL DISLOSURE
Do not take the content from these blogs as law. I'm never going to say "this will be in x.x version" or "this is ready to be used right now". There's going to be a lot of R&D discussion. I might even post a discussion I had with Melv that ended up being scrapped. It might be useful for you to understand how we communicate internally, or amusing to see the mad scientists we really are. I will not post timelines. I will not post release dates. I will not commit the team to something we cannot deliver on.
What is a module?
I've mentioned our module system in a few different blogs and posts, but never in great detail. This is one of my favorite additions to Torque 2D. It's gone through several iterations in the past couple of months, and I'm sure it will continue to improve. However, in its current state it is fully production ready. In simple terms, a module is an isolated system of scripts, GUIs, and assets. Rather than a loose set of files, a module is has a very intuitive and strict structure. It's the closest a released Torque product has ever come to having a "plug-in" system for the editor.I'm not exaggerating when I say it is a "God send" as a Torque 2D developer. It took a bit of effort to update the existing tools to the format, but now it will be extremely easy to maintain them. Adding new modules is a breeze and will greatly speed up the development of the core product. 3rd party content developers will find the system quite useful for releasing art packs and new kits. Game developers will love how easily they can integrate their own modules and install additional packs.
Creating a module
As I mentioned before, creating a new module is extremely simple. The only pre-requisite knowledge is understanding XML editing and basic TorqueScript modification. If you have that knowledge, then you are ready to create a module for the new Torque 2D. Here is a brief list of requirements:* Proper folder structure
* Module definition
* Initialization function
* Shutdown function
* Content (assets, code, etc)
* Referenced Asset Manifest
* Declared Asset Manifest
Alright, with that list in mind let's cover each one in detail.
Folder structure
This is the loosest guideline, but I believe it is just as important as the rest of the requirements. You can structure a module however you want, but if you follow our standard your life as a developer will be much easier. Let's say I am developing a module called "Starter Template". This would be a template that contains bare minimum functionality and sample art, probably shipping with Torque 2D itself. The root folder will be named {StarterTemplate}.The next subfolder will be the version. Yes, we have a versioning system for our modules. This allows us to patch the entire editor, groups of modules, or just an individual module. Since this is a new module, the first version will be "1". When we release an updated StarterTemplate, a new sub-folder of "2" will be added.
Once we are inside of the versioned folder, the real meat of the module will be developed. Each module should have a main.cs, a module definition file, sub-folders for GUIs, scripts, and data. Optionally, it contain a Declared Asset Manifest file and/or a Referenced Asset Manifest file. Along with the module definition, these two files are all in TAML format. TAML is essentially XAML, which is a more extensible XML format. Here's the full folder structure for StarterTemplate, version 1:
[ {StarterTemplate} ]
- [1]
-- [gui]
-- [data]
-- [scripts]
-- main.cs
-- {StarterTemplate}.module.taml
-- DeclaredAssets.manifest.taml
-- ReferencedAssets.manifest.taml
Module Definition
You now have your base folder structure. The next step is to create the Module Definition. I highly recommend you use an XML editor, but any text editor will do. My personal favorite is Visual Studio. It will interpret the file as XAML and will provide all kinds of nice features, such as error reporting and syntax highlighting.<ModuleDefinition
ModuleId="{StarterGame}"
VersionId="1"
Description="Starter Game"
Group="templates"
Dependencies="{StarterGameAssets}=1,{UserAssets}=1"
ScriptFile="main.cs"
CreateFunction="initializeStarterGame"
DestroyFunction="destroyStarterGame"
ReferencedAssetManifest="^StarterGame/ReferencedAssets.Manifest.taml" />main.cs
As you can guess from looking at my example Module Definition, there is a reference to a script file called "main.cs". This is the script file that will be executed when the module is loaded. You can name it anything, but I like the standard of main.cs. It is the entry point for the module. The CreateFunction and DestroyFunction fields list the functions you should include in your main.cs. These are responsible for setup and teardown of the module.function initializeStarterGame()
{
//-----------------------------------------------------------------------------
// Load profiles
//-----------------------------------------------------------------------------
exec("./gui/profiles.cs");
//-----------------------------------------------------------------------------
// Execute scripts
//-----------------------------------------------------------------------------
exec("./scripts/someScriptFile.cs");
//-----------------------------------------------------------------------------
// Load GUIs
//-----------------------------------------------------------------------------
TamlRead("./gui/someGui.gui.taml");
//-----------------------------------------------------------------------------
// Initialization
//-----------------------------------------------------------------------------
doSomeInitialization();
}
function destroyStarterGame()
{
//-----------------------------------------------------------------------------
// Cleanup
//-----------------------------------------------------------------------------
deleteSomeObject();
}Referenced Asset Manifest
If your template uses assets, you must include a Referenced Asset Manifest. Doing so will allow the Asset Manager to scan the specified directories for assets. This is a great addition, since the Asset Manager can tell you what assets are used by the module, where they are used, when they are loaded, and so on. iTorque 2D users should know that this is the replacement for the level datablocks system. For Torque 2D users not familiar with iT2D, this basically allows for level specific asset loading. No more loading all assets up front. Just specify directories and the asset extensions to scan:<AssetManifest>
<AssetManifest.Search>
<Location
Path="^StarterGame/data/levels"
Extension="scene.taml"/>
<Location
Path="^StarterGame/gui"
Extension="gui.taml"/>
<Location
Path="^StarterGame/managed"
Extension="taml"/>
</AssetManifest.Search>
</AssetManifest>Declared Asset Manifest
The Declared Asset Manifest is mainly used in tools and art packs. Game templates rarely need to implement this. This file will inform the Asset Manager it needs to scan the module for assets it will provide. You only need to state the directories and the asset extensions.<AssetManifest>
<AssetManifest.Search>
<Location
Path="^{StarterGameAssets}/images"
Extension="asset.taml"/>
<Location
Path="^{StarterGameAssets}/animations"
Extension="asset.taml"/>
<Location
Path="^{StarterGameAssets}/audio"
Extension="asset.taml"/>
</AssetManifest.Search>
</AssetManifest>Standardization
Again, you can go against the tide and structure a module however you want. As long as you provide the right directory paths, you can get a module to work how you want. However, module developers will find our structure to be the cleanest and easiest to set up. Each of our editors consist of a single module, but a genre kit or template should generally consist of three modules:Standard:
* TemplateGame
* TemplateAssets
* TemplateTools
Example:
* StarterGame
* StarterGameAssets
* StarterGameTools
When a user creates a new project using the StarterGame template, they will be provided with sample assets, custom tools, and the core functionality.
Wrap Up
I honestly could fill up three more blogs about the module system. I've barely scratched the surface about how it works, the master object that uses it (ModuleDatabase), and how it all ties in with the asset system. I still might create another blog about how you use the ModuleDatabase in other editors and game loading. For now, I'll wrap up this blog before your heads explode (if they haven't already).Feel free to ask whatever you want in this blog's comment section. Thanks for reading!
About the author
Programmer.
#2
10/13/2012 (1:55 pm)
@Frank - Not in the traditional sense. We aren't using anything like SQL or MySQL. We have two "databases". One is the Asset Manager, accessed via AssetDatabase. The other is the Module Manager, accessed via ModuleDatabase. You use these two systems to load, query, and pull what you need. This is particularly important for the asset system, which can be its own series of blogs.
#3
10/13/2012 (1:55 pm)
As for your second question, this is not related to the component system. These are entirely new systems with a different paradigm. They are coded in C++ and exposed to TorqueScript. 
#4
10/13/2012 (2:50 pm)
Thanks for the info. This sounds really interesting. I am really interested to see what the next version of T2D looks like. 
#5
10/14/2012 (6:58 pm)
I'm sort of fond of writing my asset files in TorqueScript instead of XML. All the cool languages do it. :) Ah well. I'm sure this will be nice too.
#6
This would be like Visual Studio or other IDEs where you can just have a source file and it assumes it should compile it in. Make sense?
In other words, if I put another "player.png" file in my images folder then an asset named "player" will exist and I can just use it.
10/14/2012 (7:00 pm)
Another idea about module loading. It would be nice if you could assume every image/sound/whatever in the appropriate directory is an "active" asset. Then you would not need a file that repeats a list of file names that are already in the directory.This would be like Visual Studio or other IDEs where you can just have a source file and it assumes it should compile it in. Make sense?
In other words, if I put another "player.png" file in my images folder then an asset named "player" will exist and I can just use it.
#7
10/14/2012 (9:03 pm)
The list is probably not to tell what's active, but what level it's active in, and when to load the asset.
#8
10/15/2012 (7:48 am)
@Charlie - Good thoughts. A lot of this will make more sense when I post more info about the asset management system. 
#9
The "asset file" is a companion to the actual asset that contains some basic descriptive information that will let you sort and search through assets all without having to bring every one of those images and sounds (and other types as we find need) into memory. It is very much faster than the old way. The only time you really need to load the asset itself is if you need physical information (height and width of an image, sound playback duration) about the asset in question, and in the editor this usually coincides with loading it anyway.
It sounds weird, but having worked it both directions I can tell you it is a huge improvement.
Note: We don't keep a file with a list of all assets - we just point to the folders we want scanned at module load. The asset manager then looks for asset files and keeps track of them. You can have multiple assets with the same name across multiple modules if you like; assets are qualified with their module names.
10/16/2012 (5:53 am)
We cheated and used a script to generate the asset descriptors. Some manual tweaking ensued.The "asset file" is a companion to the actual asset that contains some basic descriptive information that will let you sort and search through assets all without having to bring every one of those images and sounds (and other types as we find need) into memory. It is very much faster than the old way. The only time you really need to load the asset itself is if you need physical information (height and width of an image, sound playback duration) about the asset in question, and in the editor this usually coincides with loading it anyway.
It sounds weird, but having worked it both directions I can tell you it is a huge improvement.
Note: We don't keep a file with a list of all assets - we just point to the folders we want scanned at module load. The asset manager then looks for asset files and keeps track of them. You can have multiple assets with the same name across multiple modules if you like; assets are qualified with their module names.
#10
10/16/2012 (7:41 am)
Just wanted to say this looks awesome. I hope to have something more constructive later! 
#11
We keep talking about Taml but it's essentially a lightweight version of XAML i.e.
We use this for all declarations and game state such as assets, scenes, GUIs etc.
Essentially elements are type names, attributes are properties. There's object auto-referencing and custom object write/read. Taml can read/write in both XML and binary (binary can be compressed). Taml can read/write any SimObject. It provides custom serialization features and much more.
The module manager can be asked to scan any folder or sub-folders for Taml module definition files and this is done both in the editor and in-game and it's super-fast. This process is simply loading a handful of small XML files and nothing else. At this point it "knows" about all modules but they are not loaded until asked for.
You can load/unload a module(s) either by group or explicitly by its module-id. You can assign a module to a group such as "CoreTools" if you wish and using the following code you could load any of the "core tools" up:
10/17/2012 (7:21 am)
The module system is pretty simple to use but internally there's a lot going on. Thankfully it's all C++ and nothing whatsoever to configure in TorqueScript. A module is nothing more than a simple TAML (xml) file that provides some basic details such as moduleId, version, group, module dependencies (etc) and optional stuff like entry-script, create and destroy functions etc.We keep talking about Taml but it's essentially a lightweight version of XAML i.e.
<Scene>
<Sprite Position="100,200" Animation="{Explosions}:BigBang"/>
<Scroller Size="1024,768" Animation="{Backgrounds}:WavingGrass"/>
</Scene>We use this for all declarations and game state such as assets, scenes, GUIs etc.
Essentially elements are type names, attributes are properties. There's object auto-referencing and custom object write/read. Taml can read/write in both XML and binary (binary can be compressed). Taml can read/write any SimObject. It provides custom serialization features and much more.
The module manager can be asked to scan any folder or sub-folders for Taml module definition files and this is done both in the editor and in-game and it's super-fast. This process is simply loading a handful of small XML files and nothing else. At this point it "knows" about all modules but they are not loaded until asked for.
You can load/unload a module(s) either by group or explicitly by its module-id. You can assign a module to a group such as "CoreTools" if you wish and using the following code you could load any of the "core tools" up:
ModuleDatabase.loadGroup( "CoreTools" ); ... ModuleDatabase.unloadGroup( "CoreTools" );This is the preferred method as you load module groups at discreet stages rather than loading everything up in one go, essentially JIT. Also, it decouples the code loading those tools from the knowledge of which specific tools are loaded/unload. It only knows that the (in this case) "core tools" must be loaded/unload at that point in time.
#12
Even more deeper is module versions. The module system can handle concurrent modules of different versions. When you ask for a module group to be loaded, the latest version will be used. This can (and is) overriden by module dependencies. When a module is created, any modules it depends on are declared. Not only that but the module can specify the module at any version ("*") or at a specific version.
The loading rules here are hard to explain but it does mean that you can generate a game that uses specific game modules at specific versions and just state a module at its latest version. We can then update the modules a game is using to their latest counterparts unless there is a strict version dependency.
When we generate a game project, we don't simply copy a bunch of code and then have a game project which apart from game-state cannot be updated. Games are composed of modules i.e. a game-boot, game-core, game-xxx etc. During development we're constantly updating these modules i.e. "GameCore" internally. When we do this any exist games on developers machines will get updated (synchronized) next time they load up that project!
This can be done because the module manager offers the ability to ensure that the modules are at the best version they can be.
This has an advantage for development but it also means that we can update the product with new versions across the net. Actually we can update a module in one of two ways: we update its version Id (breaking change) or its build Id (non-breaking, backwards compatible change). When the product is updated, if we've made a non-breaking change then we can issue a module with a build-id change but keep the version the same. This is essentially replacing the module in its entirety. If we issue with a new version then that version sits side-by-side the same module at a different version meaning both are available but NOT at the same time. It means a new version of the module doesn't replace an older version and allows projects that must use it to continue to work. We can, of course, deprecate modules as well.
10/17/2012 (7:21 am)
In loading a module group, obviously all the modules in that group are loaded however the processing goes deeper than that. Any modules which are dependent upon other modules are gathered first. In actual fact, a load graph of modules needed to be loaded is generated. Any required modules are loaded (and any dependencies they have). Obviously if a module is already loaded then it has its reference increased (yes, modules use automatic reference counting).Even more deeper is module versions. The module system can handle concurrent modules of different versions. When you ask for a module group to be loaded, the latest version will be used. This can (and is) overriden by module dependencies. When a module is created, any modules it depends on are declared. Not only that but the module can specify the module at any version ("*") or at a specific version.
The loading rules here are hard to explain but it does mean that you can generate a game that uses specific game modules at specific versions and just state a module at its latest version. We can then update the modules a game is using to their latest counterparts unless there is a strict version dependency.
When we generate a game project, we don't simply copy a bunch of code and then have a game project which apart from game-state cannot be updated. Games are composed of modules i.e. a game-boot, game-core, game-xxx etc. During development we're constantly updating these modules i.e. "GameCore" internally. When we do this any exist games on developers machines will get updated (synchronized) next time they load up that project!
This can be done because the module manager offers the ability to ensure that the modules are at the best version they can be.
This has an advantage for development but it also means that we can update the product with new versions across the net. Actually we can update a module in one of two ways: we update its version Id (breaking change) or its build Id (non-breaking, backwards compatible change). When the product is updated, if we've made a non-breaking change then we can issue a module with a build-id change but keep the version the same. This is essentially replacing the module in its entirety. If we issue with a new version then that version sits side-by-side the same module at a different version meaning both are available but NOT at the same time. It means a new version of the module doesn't replace an older version and allows projects that must use it to continue to work. We can, of course, deprecate modules as well.
#13
With all the above however you'd be forgiven for thinking that modules are complex and internally they are but using them is easy. In the end, if you create a folder and generate a basic module definition file then its available to the module manager:
<ModuleDefinition
ModuleId="MyCoolModule"
Version="1"/>
That's the bare minimum definition but you can add a whole bunch of extra options if you so choose. These are just attributes in the file.
10/17/2012 (7:22 am)
Also, modules don't just contain one type of data. We use modules to contain the usual TorqueScript code containing functionality but also a module that contains only assets (we call these internally an "asset pack") as well as a module that is a binary tool. The module is used as a multi-functional, unit-of-versioning for code, data, executables etc.With all the above however you'd be forgiven for thinking that modules are complex and internally they are but using them is easy. In the end, if you create a folder and generate a basic module definition file then its available to the module manager:
<ModuleDefinition
ModuleId="MyCoolModule"
Version="1"/>
That's the bare minimum definition but you can add a whole bunch of extra options if you so choose. These are just attributes in the file.
#14
Currently there's an ImageAsset, AnimationAsset and SoundAsset although there's a few more to follow (particle asset etc) and generating new asset types is easy as there's a common base-class (AssetBase) that does nearly all the work.
In terms of generating asset descriptions, one thing to bear in mind is that they don't just announce a file, they provide configuration of the asset e.g. the cell width / height of an image-asset etc. Some assets are dependent upon other assets i.e. an AnimationAsset refers to an ImageAsset. Also, some assets refer to raw files and that is also defined.
Systems that use raw files don't use assets and this is, at the moment, many of the obscure GUI classes, most of which are not used very often.
Right now there's no "t2dStaticSprite" and "t2dAnimatedSprite", just a "Sprite" type. It's on types like this that you can assign an asset whether that be an ImageAsset (static) or AnimationAsset (dynamic) in this case. All the other "2D" scene objects are the same.
The asset system can be told to scan any folder for assets and it discovers them all and generates a unique asset-Id for each based upon the module which they were discovered and the asset-name. In reality, when a module is loaded it provides a callback both internally within the engine and to the scripts. Internally the asset system hooks itself into that callback and process any assets in the module being loaded. The reverse is also true, when a module is unloaded, so are the assets.
The asset system is thus armed with knowledge of all assets (known as declared assets). You can then perform many queries on the asset system (known internally as the asset database) and assign those assets to objects.
All declared assets are known but they are not loaded initially. When an asset reference is assigned to an object then the object will acquire the asset resulting in the asset manager loading the asset or simply passing the asset back if it was already loaded. All assets are reference-counted so that they will automatically be unloaded when not in use. You can, of course, override these on a global or per-asset basis.
10/17/2012 (7:22 am)
Assets are tied to modules in a subtle way...Currently there's an ImageAsset, AnimationAsset and SoundAsset although there's a few more to follow (particle asset etc) and generating new asset types is easy as there's a common base-class (AssetBase) that does nearly all the work.
In terms of generating asset descriptions, one thing to bear in mind is that they don't just announce a file, they provide configuration of the asset e.g. the cell width / height of an image-asset etc. Some assets are dependent upon other assets i.e. an AnimationAsset refers to an ImageAsset. Also, some assets refer to raw files and that is also defined.
Systems that use raw files don't use assets and this is, at the moment, many of the obscure GUI classes, most of which are not used very often.
Right now there's no "t2dStaticSprite" and "t2dAnimatedSprite", just a "Sprite" type. It's on types like this that you can assign an asset whether that be an ImageAsset (static) or AnimationAsset (dynamic) in this case. All the other "2D" scene objects are the same.
The asset system can be told to scan any folder for assets and it discovers them all and generates a unique asset-Id for each based upon the module which they were discovered and the asset-name. In reality, when a module is loaded it provides a callback both internally within the engine and to the scripts. Internally the asset system hooks itself into that callback and process any assets in the module being loaded. The reverse is also true, when a module is unloaded, so are the assets.
The asset system is thus armed with knowledge of all assets (known as declared assets). You can then perform many queries on the asset system (known internally as the asset database) and assign those assets to objects.
All declared assets are known but they are not loaded initially. When an asset reference is assigned to an object then the object will acquire the asset resulting in the asset manager loading the asset or simply passing the asset back if it was already loaded. All assets are reference-counted so that they will automatically be unloaded when not in use. You can, of course, override these on a global or per-asset basis.
#15
This leads to code similar to this:
The asset manager not only manages declared assets but it can also manage asset references. This is done when a module is loaded although it's only hooked-up for the editor but there are theoretical uses in-game.
This means that the asset manager knows the following about assets:
I wanted to add finally that handling assets in C++ is also easy with a template smart pointer like this:
10/17/2012 (7:23 am)
You can also acquire/release an asset in scripts if you so wish although that's mainly done in editors.This leads to code similar to this:
%sprite = new Sprite();
%sprite.playAnimation( "{UserAssets}:FunkyAnimation" );The asset manager not only manages declared assets but it can also manage asset references. This is done when a module is loaded although it's only hooked-up for the editor but there are theoretical uses in-game.
This means that the asset manager knows the following about assets:
- That an asset exists and its configuration so it can be loaded
- Any assets that the asset depends on so that if the asset is loaded, the other assets are loaded prior to it being loaded.
- Any raw-file references for an asset. If you ask the asset manager to delete an asset it knows about the raw files too. It also knows if other assets share that raw file.
- What files reference the asset. This means we know where an asset is used, how many times and obviously if it's not used at all. This can be used to actions such as renaming an asset name. If this is done, not only is the asset definition updated on disk but also all references throughout the game. This also includes live reference in-memory.
- Asset queries. The asset manager can perform layered queries i.e. searching for all assets, asset names (including partial matches), categories, types, asset scope (internal/external/private) etc. You can perform queries such as asset by name then filter further by category etc. There's a specific "AssetQuery" type exposed to the scripts which acts as a token object that you can pass back/forth between the asset-manager and the scripts thus removing the need for the slow and costly use of large strings containing the results. When you're done you can iterate the asset-query to get the results.
- Asset tagging. Assets can be tagged (simply names) and you can obviously query by tag(s).
I wanted to add finally that handling assets in C++ is also easy with a template smart pointer like this:
AssetPtr<ImageAsset> image = "{UserAssets}:NinjaImage";These asset pointers not only deal with acquisition and release (asset scope) but also Taml can persist them.
#16
Melv.
10/17/2012 (7:25 am)
I'm sure every piece of info raises more questions and nothing replaces a decent manual but hopefully this starts to paint a rough picture of it.Melv.
#17
10/17/2012 (8:14 am)
If all this is a precursor to editing/developing a game while it is live, then it will be well worth it. :)
#18
10/24/2012 (8:31 pm)
Reminds me of Eclipse. Esp. with the "manifest" files. Kinda cool! 
#19
My question is that, with the possibility of 3rd-party module integration, will there be some form of real-time (well, at least a per-launch solution) notification for when new versions of modules are available?
I think an addition to the editor for something like this would be great, allowing for true test cases to be established. This way, developers can easily and quite readily test new versions of modules which they declare as a dependency without the need for (as much) in-house tracking and logging of said modules.
A GG-hosted, database-driven module back-end would work wonders toward that end.
Aside from that desire, I think the module system shows great potential in addressing one of the main issues I've come across during iDevice development: Versioning (<-- really? That's not a word?!?) of feature sets for each device/iOS...um...version.
10/25/2012 (10:01 am)
Very impressive indeed. I can see why Mich is so excited about this addition to the system.My question is that, with the possibility of 3rd-party module integration, will there be some form of real-time (well, at least a per-launch solution) notification for when new versions of modules are available?
I think an addition to the editor for something like this would be great, allowing for true test cases to be established. This way, developers can easily and quite readily test new versions of modules which they declare as a dependency without the need for (as much) in-house tracking and logging of said modules.
A GG-hosted, database-driven module back-end would work wonders toward that end.
Aside from that desire, I think the module system shows great potential in addressing one of the main issues I've come across during iDevice development: Versioning (<-- really? That's not a word?!?) of feature sets for each device/iOS...um...version.
#20
1. Torque still cannot unload code. If a module has been loaded, the scripts that have been executed are already in memory. If the same module has been updated, a restart of the editor will need to happen.
2. For a tool like 3 Step Studio, there is no code modification. The user does not write any source or script code. Everything is closed and controlled by us, which means we do not have to worry about stomping on anyone's changes. That's not the case with Torque 2D. You all are professional developers. There is no telling what modifications you have made to the files we need to patch. Sure, we could push a new version of a module out. However, that might be dependent on source changes we've. Thus, a diff between source and a full binary recompile would be required.
Very tricky situation...now, that does not necessarily mean 3rd party developers could not utilize the system. Even if we do not implement it for Torque 2D, you might find it useful for game and tool patching.
10/25/2012 (11:10 am)
@Brian - We've already implemented that in 3 Step Studio. Whenever a user is logged in via the tool, the back-end will check to see if there are any updates for the modules the user has installed. If there are, the user will be asked if they wish to install the updates. We can perform this manually or have it running on a schedule. There are two tricky parts with this.1. Torque still cannot unload code. If a module has been loaded, the scripts that have been executed are already in memory. If the same module has been updated, a restart of the editor will need to happen.
2. For a tool like 3 Step Studio, there is no code modification. The user does not write any source or script code. Everything is closed and controlled by us, which means we do not have to worry about stomping on anyone's changes. That's not the case with Torque 2D. You all are professional developers. There is no telling what modifications you have made to the files we need to patch. Sure, we could push a new version of a module out. However, that might be dependent on source changes we've. Thus, a diff between source and a full binary recompile would be required.
Very tricky situation...now, that does not necessarily mean 3rd party developers could not utilize the system. Even if we do not implement it for Torque 2D, you might find it useful for game and tool patching.
Torque Owner Demolishun
DemolishunConsulting Rocks!
Is this related to a component system except just for scripting?