Obsidian Games
-
Posts
145 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Obsidian Games
-
-
Chris, if you read this, can you confirm that AMXdtsPlus will be able to handle 5-point patches in the near future as this has obvious implications for the methods we use to produce the game models?
Paul,
First off, congrats on the exports, they're looking great!
As for five point patches, AMXdtsPlus currently *does* export them. The Hash SDK does the conversion to multiple smaller patches on export, so there's nothing I can do to make it export differently.
If they're not exporting the way you want, you might want to try either of the following methods to clean it up:
1) Delete the five point patch in A:M, and manually replace it with smaller triangle patches. This way you can control how it looks before exporting it.
2) Export the model from A:M to the PLY format, and then reimport it into a new model in A:M. The five point patch should have gone through the same conversion as AMXdtsPlus would go through, and you can clean up any 5 point patches before exporting using AMXdtsPlus.
I hope this helps,
-
Answers are below...
I can occassionally export the bones but getting the Torque Show Tool to display a whole sequence just isn't happening. It will play just a couple of frames from a one second sequence.
This is normal. The unregistered version only exports the first 5 frames of an action. You need to register to get texture and full animation export.
Even using your Thom project I am unable to export a model. I must be missing something. Can you try running that Thom project from A:M13 and see if you can export the DTS and DTQ files to a new folder? Maybe I should try all this again in A:M 12 as I have only tested A:M 13 so far.
I just tried exporting the Thom project, as is, to a brand new folder with no config file. I got an error that the plugin could not find a config file (which was expected), but the model and animations exported just fine.
Some new questions for you:
1) Are spaces allowed in bone names such as, 'thigh left', or must they use the underscore like this, 'thigh_left'?
Spaces are allowed in names. The Thom model from the file pack uses spaces in the bone names.
2) Are frames per second important? If I export a sequence that was animated at 24 fps will Torque accept it? Please note that I have been trying both 24 fps and 30 fps but haven't noticed any change in the results.
While some of the code is in there to accept non-default frame rates, it's currently locked in at 30 FPS. This is one of the things I will be working on.
3) If I export a model without any decals do I set 'details' to 0? I have tried eliminating it completely but AMXdtsPlus detects it and refuses to export.
The detail markers are required, but have nothing to do with decals. I wrote a couple of paragraphs describing the detail markers in an earlier post in this thread. Please search above for it (it starts with "The detail marker has nothing to do with textures/images").
I may not be able to get back to this for a little while so hopefully someone else will take up the challenge and show the way. I've given it my best but I'm completely stumped.
If you continue to have trouble exporting, I'd be happy to take a look at one of your project files that you've set up.
-
Paul,
Wow... That's pretty much exactly how I would recommend you setup the workflow. Very solid, and it's keeps all of your models from the movie and game separate (but easily available as reference). The template project especially is a good idea, and should save lots of time when setting up similar models.
I only have a few, very minor, comments to make, which have nothing to do with your workflow. As before, I'll bold your step/question and respond afterwards.
3) Make any alterations to the model such as stripping splines, ensuring 5 point patches are all removed.
No changes here, but a few suggestions if you're considering multiple levels of detail. Depending on how detailed you want the "up close" version of the models to be, you might not want to strip too many splines to start. You could always have your high level detail model as close (in detail) to the movie model as possible, but strip out splines for the lower LODs.
On the flip side, if any of the models needs *more* detail, you could always try something like this -- Export using the PLY format (included with A:M), using multiple patches per poly. Then import that model back into A:M, and voila, you get lots more splines. This may still require cleanup, and it won't work well with complex bone setups, but if you're redesigning your bone structure, this shouldn't be a problem.
6) In bones mode, rotate the model bone so that the model appears to be standing on it's head and facing me when viewed from Top View (key 5).
Yes, exactly. For Torque models, positive Z is up, positive Y is forward, and positive X is to the right.
8) Right click on the model icon, in the PWS, and navigate to plugins/export/AMXdtsPlus and save models and action sequences.
This is absolutely correct, but there is a possible gotcha depending on how you export actions. I've seen this issue when reading about other Torque exporters, so I think it's an underlying issue with the Torque code. I'll continue to look into it in case it's not though.
When exporting animations, you might need to export them separately from the model -- ie, export the model to a .DTS file and then export the actions to a .DSQ file. You can then recombine them in the Torque ShowTool or in the engine. The issue that crops up is that sometimes when you export a model *and* animations to the same DTS file, some of the animations will be all out of whack (I believe it has to do with the default pose not being handled correctly by the animations). If you ever see this issue, please try to export your action to a separate DSQ file and see if it works that way.
Don't worry about my action object question. The 'dump' file didn't throw up any errors concerning the action object that I had in my actions. I need to discover how Torque handles objects that the characters carry and use. Things like Tinman's axe. Is it possible to have Tinman aquire and use his axe in Torque or will the axe need to be a permanent part of the Tinman model?
Ok, sounds good. If you find anything wrong with these action objects though, please let me know.
As for objects like the axe, you absolutely can keep the axe as a separate object from the character. In fact, this is where the config file comes into play. Real quick short version -- the config file used by the exporter is used (among other things) to cull unneeded bones, and to force the exporter to keep other bones. By default, the DTS format will cull out any bone that does not have vertices attached to it. (As a side note, this may be what allows complex rigs to work).
What you do is set up an empty bone on your model's hand, and name it something like "RightHandMount". Then make an entry in your config file under the "Always Export" section with that name. Export the model (make sure to look at the dump.dmp and confirm that the new entry was read from the config file). Then go to your axe model, and export that.
When you have both models, go into the ShowTool, load the axe and then TinMan, and use the "Mount Objects" function to mount your axe to the "RightHandMount" node on TinMan. You may need to read the docs on ShowTool to figure out how to get mounts to work, and it may require some other work (the mounted object will inherit the bone rotation/translation of your mount node), but this should be relatively easy to accomplish.
Anyway, do you see any problems with this workflow?
Again, this looks great. Thank you for sharing it, I would recommend it to everyone involved in the project.
-
Paul,
Here's a response to your second list of questions. I just saw that you posted a new message, so I'll take a look at that as soon as I can.
I am still getting an error message when AMXdts creates a dts file but when opened the file in the Torque viewer the model doesn't show up.
The 'dump file' shows alot of 'Export Error' statements when it gets to the 'Adding sequence' sections.
I'm not sure what the problem is. If you want to send me your full project file, or attach it to a response here, I will take a look and see what I can find.
Can actions that were created an a full scale model in A:M be applied to the model when it is scaled down to .001 of it's original size? I can see how rotations would be unaffected but translations would remain at their A:M scale and so would be useless. I think that is what I am seeing in my actions.
I would highly recommend that all actions be set up on the model once you've created it at the proper size and orientation. However, do the actions work inside A:M after you've made these changes? If they work in A:M, but they don't work on export, please send/attach the project and I'll take a look.
This raises questions about whether any animation data could be transfered from the TWO movie to the TWO game. It looks like all game animation would have to be done afresh using the scaled down models. Thats okay, so long as we recognise this from the start. Having said that I would prefer it if some hidden magic where added to the exporter to automatically handle the donkey work like scaling, rotating and converting the models and actions from A:M space to Torque space. As one unit of measurement in Torque space represents 1 metre and 1 unit of space in A:M generally equals 1 centimetre it would make sense to me to apply some automatic conversion routine within AMXdts which divides all model coordinates by 100 if an option is selected in the exporter interface.
As before, I'm not sure if it will work. Trial and error may be your best bet to see if movie models/animations can be modified to work with the game models/animations. I do understand and can appreciate that it would be nice if a lot of the A:M-space to Torque-space work could be done automatically. Some of it may be possible, and is certainly something I could consider as additional features once the base feature set is complete. However, at the base of it, AMXdtsPlus is an exporter only, and it's function is to export ready-made objects from A:M.
Of course it is very possible, in fact very likely, that I have got this all wrong. Just my confusion. Nothing that a little conversation can't sort out. So am I way off course again?
I don't think you have it all wrong; not at all. Every question you've asked has been a valid one, and I appreciate it. If I don't know what the users of the plugin are thinking, there's not much I can do to improve it, right?
That said, I do have some advice for anyone learning to use AMXdtsPlus. When learning the exporter, I would definitely recommend starting small and working your way up. Looking over the models in the file pack would probably be a good start, and then maybe copying and modifying them. Don't try all of the features at once. Start with a static object, and get that to export. Mess around with the project setup, and see what types of DTS errors you get (the dump.dmp file is a great learning tool for this). Once you're comfortable with that, try out a model with bones, etc. I wouldn't even think about animation until you're comfortable with non-animated models. Much like learning A:M (or anything, for that matter), I think it may be overwhelming to go all out at first. If you take it slow, I think it will make it a lot easier down the road.
-
Paul, I'll answer your first post first. I've bolded your questions, and my answers follow.
1) The bounding box: This is not well documented but I assume that a bounding box is just a standard 6 patch box which describes an area around your model that is large enough to contain all the parts of your model through any of it's actions. So this takes a bit of experimenting and foresight before you can be sure that it is set to the optimum size. I gather that this box is used within Torque for a number of things, including collision detection? This box must be held in A:M as a separate model and named 'bounds'. The orientation of the bounding box must match the orientation of the rotated and scaled model?
You pretty much got this one dead on, except for collision detection. There are separate objects (LOS & Col) which are used for collision detection. The bounding box must encompass your entire model during all all animations, where as you can get a little more fine tuned when creating LOS & Col (line-of-sight & collision) objects.
2) The base01 folder contains two items, BoneLink and detail#. Are these just nulls which are created in the PWS? Does the number which follows 'detail' describe the height, in pixels, of the image map that will be generated from the model and exported to Torque? If this is correct does it have to match the size of the image used in your decals or does this just set the size of the image that will be generated for Torque?
Yes, the BoneLink and detail# are just markers that tell the exporter where, when, and how to export objects. DTS was originally designed to work with 3DSMax, and was tuned to their workspace. I've never used it, but from the pictures I've seen, the skeleton exists separately from the model in the project workspace, and the root node was located under the base01 folder. To simulate this, I implemented the BoneLink object, which basically tells the exporter that when you get to this object, create the bone hierarchy from the main model.
The detail marker has nothing to do with textures/images. The detail marker represents the size of the model and how it gets displayed in game based on pixel height. The number at the end has to match the number at the end of your model (ie a detail marker named "detail64" would match up with a model named "Thom64"). If you are doing a single level of detail (LOD) model, this number can be any positive number, it should not matter. It's only if you're doing multiple levels of detail that the number becomes important.
For example, take the SphereLOD_BB example model from the file pack. It has 3 detail markers - 2, 64, and 128. When the model is close, and the model size on screen is larger than 128 pixels, the highest detail version of the model (128) is displayed. When the model size on screen is between 64-128 pixels, the middle detail version is used (64). When the object is far away, and takes up less than 64 pixels, the smallest detail version of the model is displayed on screen (2, which in this case is a billboard model, but ignore that part for now).
By using multiple LODs, you can speed up the engine, sometimes dramatically. If a model is far away on screen, there's really no need to render all of that detail, and you can increase render speed by having the engine draw a simpler version of the model.
3) Does 'BoneLink' have to be the top item in the 'base01' folder?
The BoneLink object needs to be located at the top level inside base01, but does not need to be the top item.
4) When creating models for DTS export should I have just one model/character per project or is it possible to have a project with many models setup for DTS export?
Each A:M project is for a single DTS model export. You can have multiple copies of that one model if you're doing multiple levels of detail (LOD), but you should not have one large project with different models in it.
5) Can you describe the difference between a standard mesh and a skinned mesh? Is it just that a standard mesh has no bones and a skinned mesh does?
That's basically it. Standard meshes are mainly meant for static objects (boxes, trees, etc) where as skinned meshes are for boned/animated characters.
6) I notice that there are no relationships in the Thom project. Should they be stripped out of models that are created in A:M? If this is so then how can actions be exported? I imagine this will require me to study the Torque documentation in order to understand how Torque handles bones.
I'm not sure what you mean by relationships. Do you mean complex bone rigs? If so, I'll answer that one below. If not though, I'm a bit confused, as the actions for the Thom project export correctly.
7) I have several actions that have an action object in them. Should I delete this object from the project and save it as a separate DTS model via another project?
Again, I'm not sure what you mean by action objects. Can you please describe what that is, and why you think it is/could be a problem?
8) There is no documentation regarding rigging. What are the requirements and are there compatibility problems with complex rigs such as TSM2 or the new squetch rig? I notice that after scaling and rotating my model that the TSM2 foot controls have not scaled and so my actions are no longer correct. The Thom example seems to use a very basic rig. A paragraph or two, in the documentation, about rigging requirements would be very useful to all AMXdtsPlus users.
I have not tested whether complex rigs work with AMXdtsPlus, but it's unlikely that they will be supported (they're not supported with AMXtex). It might be possible to work something out where the model can be designed with an advanced rig, and then the config file can be used to cull out all of the advanced rig bones. I will try to test one out when I get a chance, but I can't guarantee anything.
I'm sure that I will have more questions, particularly regarding the less documented areas.
Whenever you come up with more questions, let me know, that's what I'm here for.
For now, there is an important point that I'd like to make with regards to designing models for game export, which I cannot stress enough. Modelling for animation and modelling for games are two completely different beasts. When you're modelling for animation, you can afford to use as many objects (patches, textures, bones) as you want, since the end result is an animation of the model, and not the model itself. When you're building models for games though, you need to design them to use the fewest objects possible, since the model itself will be used in the game. Every additional patch, texture, and bone adds to the complexity of your model. The more complex a model is, the slower it will render in the game engine. Individually this might not be a problem, but when you think about the possibility of have 10's or 100's of models on screen at once, you might really begin to see the difference.
-
Paul,
Not a problem at all. I know a lot of people are excited to get this project going, so it's certainly understandable. Especially as it starts up, I know there will be a lot of questions, and that's what I'm here for. These are the types of questions that will help me flesh out the documentation, too, so keep them coming.
On that note, I see you started a thread with more questions in the game dev forums, so I'll go get to work on those.
-
Excuse me if somone has already posted this link. I couldn't see one in my quick scan of this thread.
This is for a 30 day trial of the Torque Show Tool:
It will probably take me 30 days to learn the interface.
If you just want to get an overview of the product lookhere
I don't know if it's changed since Garage Games initially released ShowTool Pro, but at least originally, the "30 days" does not mean 30 consecutive days. You can use it one day, then wait a week, and the next time you start it up, you'll only be on day 2 of the trial.
Also, I can't speak highly enough of this tool. It is so much easier to use and more powerful than the default Torque demo viewer (which, if you're curious, you can run from the Torque demo by running "<INSTALLDIR>\Torque Game Engine Demo\demo.exe" -show).
-
Okay. I downloaded the plugins again, Chris, but I am still getting the same errors.
Here are the errors that I get if I try to export the model and actions:
And here is what I get if I try to export just the model:
This model has some five-point patches in it. Could that be the problem?
I will try exporting my test model that is free of 5-point patches and see if I get better results.
Paul,
Thank you for the screenshots, they're very helpful. I don't think there's a problem with the plugin, though -- It looks like the issues you are seeing have to do with the way your A:M project is set up. You need to have a very specific A:M project set up when exporting to the DTS format. The AMXdtsPlus help docs (though not yet complete) and File Pack should give you some good examples as to how you need to set up your A:M project for export.
There are a couple of gotchas that I can see from your screenshots --
1) The config file error - You're getting this error because the plugin cannot find a config file in the directory you're exporting to. You can find out what files it's searching for by opening up the "dump.dmp" file that's created after export (it will be in the same directory as the exported model). The exporter will search for the config file using a couple of names -- <MODELNAME>.cfg and the default dtsScene.cfg. The config file is not absolutely neccessary, but it can help if you need to include or exclude certain nodes. There is not a lot of information in the Help docs yet, but you can get an idea of what it's looking for by looking at the config files in the File Pack.
2) The "No subtree found" error - This error shows up when you have an improper hierarchy or missing items in your A:M Project config file. The project needs to be set up in a specific way (including subfolders to represent subtree's) in order to export a model to the DTS format. The help docs give a few basic examples of what the heirarchy should look like, and you can look at the projects in the File Pack for more details.
3) No "bounds" node - You didn't get this error yet, but from the look of the export window screenshot, you do not have a "bounds" model in your hierarchy. Every model that you want to export to DTS needs to have a bounds node included. The help docs go into more detail about how to set this up.
4) Model naming conventions - Model need to have numbers at the end of them to represent detail sizes in the game engine. The help docs describe how the names need to be set up in your A:M project.
Hopefully this will help you (and others) out. The DTS format is great in that is allows you to store a lot of information in the model file. However, the flip side is that a lot more work needs to go into setting up the export. Once you get used to it, it's not a big deal, but from my own experience, it's definitely confusing at first.
I would definitely recommend looking at the models in File Pack, and using them until you get comfortable with the project setup. And if you find anything in the Help docs that needs more information added, or any areas that I did not explain very well, please let me know and I'll make sure I cover it.
Thanks,
-
Regarding Obsidian Games AMXdtsPlus exporter: I don't think there is a trial version. My attempts to export anything produced a 'config file error'. Full product is required now, I think
Paul,
Where are you getting "config file error"? I just uploaded a new version of AMXdtsPlus in the last hour or so, so if you downloaded when that was happening, you might have gotten an error. The trial version should still work though, I have no plans to discontinue it.
Thanks,
-
Thanks guys, I appreciate it!
Just a quick note for everyone. If you purchase AMXdtsPlus going forward, please download the new Beta-5 version of the exporter (or newer, if available). New license codes will not work with previous versions of AMXdtsPlus (though codes for existing owners work fine in any version).
-
The AMXdtsPlus plugin is now on sale at the introductory price of $14.99 (regularly $19.99). You can purchase it by visiting the Obsidian Games Purchase Page.
The plugin is still in beta (there is a new Beta-4 version with some minor fixes), and there are still some features (and documentation) to be added. However, for those people who want to start exporting their models to the Torque Engine with textures and full animations, and want to get in at a discounted price, this is your opportunity.
I look forward to seeing what people can do with the plugin. As always, please email/pm me if you find any issues with the plugin or purchase process.
Thanks!
-
There is the Torque Developer's Network that you'll need the username and password to from the license we have. I pinged Steve to get that, and as soon as I do I'll email it to you.
Please be careful with regard to sharing a Torque license. Unless Hash has a special arrangement with Garage Games, Torque licenses are single person only, and cannot be shared or transfered. One license = one person = one login = one programmer access to Torque code.
-
Wow, very cool! I can't wait to see what comes of this effort. That's really cool that you'll be using Torque too, it should definitely be a good test of the exporter's abilities. If any issues do come up with the Torque exporter, please let me know and I'll do my best to fix them.
-
I've just uploaded the Beta-3 version of AMXdtsPlus. This version has some under-the-covers fixes, as well as a bug fix for an action-export error dialog which should not have been displayed the way it was.
There is also a version for OSX Panther for A:M v12. There was only one thing that I could not get to work, and that's the generation of IFL placeholder images. This is essentially just a copy of one of the IFL images to a placeholder image with a different name, and is what's displayed when an IFL object hast not yet been animated. There is a dialog box which will give details when this is needed.
As for the error dialog fix mentioned above, there is a requirement that I had forgotten to mention. When exporting actions, you need to have each action actively open in the project workspace. The exporter uses the live action, so it has to be open or you'll get a mashed up animation. If you don't have an action open, you'll get the error dialog (if you're still running Beta-2) or a number of messages in the dump.dmp file (if you're running Beta-3).
Enjoy!
-
Dennis -- This looks great! Although I have not used 3D GameStudio, the tutorial is very clear, and has a good balance between pictures and written descriptions.
I hope it's ok, I've added a link to the tutorial from my 3D Links page.
-
dukeschen - Thanks for the pic, I'm glad it's working for you! It's cool to see another A:M model in Torque besides the test models I've been using.
woolyloach - I haven't made any announcements yet on the GG boards. I wanted to get the initial beta out there and in limited testing before going more public with it. I will do so in the near future though, as it looks like things are going well.
ZachBG - It probably won't be long. I wanted to make sure that the plugin at least worked for people before putting out a paid version. Since it seems like there have been no major problems (none that I've been told about at least), I will look do do that soon. And I'm looking to sell it at the same price as AMXtex.
-
I've just released a Beta-2 version of AMXdtsPlus to the Obsidian Games website. This version now works with A:M v13, on both Windows and OSX Tiger.
I'm still working on a possible Panther version, but do not have any concrete info on if/when it will be available.
-
Cool... but wait, only Tiger?
Can we expect a Macintosh Panther version? A lot of us are still using this...
Thank you in advance,
Gustavo Muñoz
Gus,
I did not think this was going to be an issue. With the release of the new Hash Mac SDK (which is Tiger only) and A:M v13 (which also appears to be Tiger only), I did not think a Panther version of AMXdtsPlus would be needed.
Are there a lot of Mac users who plan to stick with A:M v12 on Panther, and not upgrade either product? If that's the case, I can try to get AMXdtsPlus to work on A:M v12 on Panther. Please let me know, either here, through PMs, or email.
Thanks,
-
I just released the initial beta version of AMXdtsPlus to the Obsidian Games website. It is available for A:M version 12 only (for now; there is an A:M bug preventing a V13 release), and is available for both Windows and Mac OSX Tiger.
This plugin uses the same setup as AMXtex -- the unregistered version cannot export textures, and only exports the first 5 frames of animation. I mainly want to see how everything runs for everyone in the unregistered mode, and if there are any major problems. If all goes well, and there aren't too many kinks to work out, the next step should be to allow for purchases, which would mean texture and full animation export would be be available.
Also available on the download page is the initial AMXdtsPlus Help File, which is currently incomplete, and the AMXdtsPlus File Pack, which includes a number of A:M Project Files along with their corresponding DTS/DSQ files.
I want to thank everyone again for all their patience while I worked on this exporter. It took a lot longer than expected, for many reasons, and I appreciate everyone's willingness to wait it out with me.
Well, that's enough from me. Please download it and take a look, and let me know what you think!
Thanks,
-
I will be starting soon. Me and my parents got the flu, I got better, my both parents ended up in the hospital with worse things but they are getting better now. So things should be back to normal around here soon. My dad's supposed to come home today.
Dennis, I'm sorry to hear about you getting the flu, that can be tough. Everything else can wait, just make sure you and your family get healthy first.
-
Great news! Paul Scott at Garage Games figured out the issues with the Torque SDK code running under GCC 4.0, and I have an initial build of AMXdtsPlus running under A:M v13 (Tiger). Animation export crashes, but model exports work. I'm still working as hard as I can to get it ready for a beta release, and will post as soon as I have something.
-
Hey Capanno
Good to see ya here on the forum. I'm glad what I said worked. If you find out what was going wrong can you post it here. I am making a a:m and gamestudio tutorial and it would help. Thanks
Capanno - I'm glad you were able to get everything working. If there are any AMXtex specific problems that you run into, please let me know.
Dennis - Great to hear about the tutorial. If it involves AMXtex at all, please let me know if you want a link from the Obsidian Games page when you're done, and I'd be happy to link to it.
-
Ive heard from some people that in order to export correctly, I need to use one texture image to texture the model with. I did that, tried diffrent image formats, still no luck.
Can someone, please, tell me how to export the model step by step with its textures. How I must texture it, etc.
Please please!
Thanx
cap
I don't use 3dgs myself, but you should not have to do anything special in order to get textures to export (assuming you have the registered version of AMXtex). Do your exported .X models show up with textures in the Microsoft .X viewer (Mesh Viewer)? One gotcha that I've seen is that you need to have your textures in the same directory. Did you make sure to do that?
-
so if i have a query on those versions , will you answer them?
If you're having any problems, I will do my best to see if I can help, or to see if the issue is still there in the new versions, but I don't plan on updating the old versions with any new changes/fixes.
Harassment process completed.
Thanks, Greg, please let me know if you hear anything. I also posted about the specific problem that I'm having on the GG message boards, to see if anyone else has come across this yet. I was able to get around the errors by effectively breaking what the functions did, and the result was empty DTS files. Hopefully someone here or on the GG site will be able to shed some light on the subject.
In the meantime, I will get back to working on the plugin!
*** A:M to Torque for game makers ***
in TWO Game
Posted
Martin,
That's great news that 5-point export is being changed/fixed. However, that was JohnArtbox's bug report, I didn't know about it until just now when I looked at the change log. My hook bug had to do with how hook cps behaved in A:M (which was different than how it correctly behaved on export), though Noel did find a new issue with how they exported, and assigned me as the submitter (I think since it came out of my first report).
And yes, I do read my email.
However, hearing this does explain one of the somewhat cryptic closing notes from the hook report. I think Bob may have done a complete overhaul and put the same (all-encompasing) closing notes in John and my cases (though not knowing about John's report at the time, I didn't fully understand what Bob meant).
In any case, this is definitely great news. As soon as the SDK is updated, I will update AMXtex and AMXdtsPlus with the new code (though I'll be on vacation this weekend, and will not be able to do anything until next week).
By the way, thank you very much for all your (and your team's) hard work on the bug reports recently. It's great to see all of these fixes going in, and it's very much appreciated.