RMMV RETRO - MZ Plugins on MV

[Drakkonis]

Really Experimental Temporal Reliability Operations - R.E.T.R.O. v0.10
Drakkonis​

Introduction
This plugin has the rather lofty goal of allowing MZ plugins that are otherwise incompatible to function in RPG Maker MV.
It is a work-in-progress, and is nowhere NEAR ready for a full release.

RETRO now has a documentation file located here. This file will provide an overview of the major elements RETRO currently enables, some of its under-the-hood supporting functions, and a detailed breakdown on manual command entry.

For MZ plugin commands, I highly recommend OcRam's RETRO Plugin Command UI. This little program was made by @OcRam specifically for RETRO. It emulates MZ's plugin command UI and builds a command string that you can just copy into MV's existing event command for plugin commands. For complex plugin commands, like some from his own plugins, this UI is practically required.

Features
RETRO's list of functional features grows with each release. For a (non-exhaustive) overview, please see the documentation text.

Previously it was brought to my attention that the method RETRO used to read plugin information was only possible on PC environments due to requiring Node.js functionality, which mobile and web versions of a game apparently don't or can't support. It originally only affected the use of MZ plugin commands. However the functionality in question has expanded slightly in scope, so adjusting the information retrieval method got pushed to the front of the line. RETRO should hopefully now be compatible with mobile/web releases, but this hasn't been tested yet.

WIP
Working through Casper's CGMZ plugin library. So far, one plugin mysteriously non-functional. No crashes on it, so figuring it out is low priority, as I've sunk too much time into it already. I'll come back to it.

How to Use
Save this plugin as "RETRO.js". Make sure it goes above all MZ plugins you're using in the plugin list.

Update to Plugin Commands (v0.10) - The MZ Plugin Command system has been overhauled a LOT. It is now capable of handling nearly any kind of command and argument list, with two exceptions. However, this also means that its usage has become very complex if the command itself has any complexity to it. To use MZ plugin commands, you will either need OcRam's RETRO Plugin Command UI(the easiest solution), or read the documentation VERY carefully(the hard, potentially painful way).

The two known exceptions to RETRO's MZ plugin command functionality are both for nested arguments. RETRO can handle an array inside a struct(object), or a struct inside an array. But it currently CANNOT handle structs inside of structs, or arrays inside of arrays. Attempting to use arguments like this will crash the game. This is planned to be remedied in the next update.

Plugin Commands / Script Calls
This plugin offers no commands, and any custom functions declared are really only useful within the plugin code itself.

Known Functional Plugins
The plugins listed here are ones that I or others have personally tested with RETRO, and can confirm are functional.
Coelocanth's Item Crafting
Drakkonis' Plugin Core
Drakkonis' TP Control

Casper Gaming Plugins - His Core is required, full functionality unknown, but no issues so far with any of his plugins on this list. Some of these plugins are compatible only because the core doesn't break with them, if they were standalone they wouldn't even need RETRO.
Casper Gaming's Achievements
Casper Gaming's Encyclopedia and Bestiary
Casper Gaming's Extra Stats
Casper Gaming's Infinite Colors
Casper Gaming's Item Crafting
Casper Gaming's Item Conditions
Casper Gaming's Menu Theme
Casper Gaming's Splash Screens
Casper Gaming's Game Info

OcRam Plugins - OcRam was kind enough to work with me on RETRO, primarily in getting his MZ plugins operational. His MZ plugins are all in their own dedicated thread.
OcRam's MZ Plugins

Partially Functional Plugins
The plugins listed here are technically functional, but currently have certain issues that will be explained for each. I intend to fix as many of these as possible.

Download
Really Experimental Temporal Reliability Operations

Useful Links
RETRO Documentation
OcRam's RETRO Plugin Command UI

Terms and Credits
This plugin is free to use in any project, commercial or otherwise. Make sure to credit myself(Drakkonis), and anyone else mentioned below:
Restart - Created FOSSIL and inspired the creation of RETRO.
OcRam - Provided substantial assistance in not only getting his plugins operational, but also provided insight that improved RETRO's efficiency in a few areas. He also created the RETRO Plugin Command UI tool, making the newly-complex plugin commands a trivial matter.

Miscellaneous
This is a work in progress, and it will probably be a long time before it's ready for a v1.0 release. As such, I don't recommend using it in its current form for a finished/released game unless its current compatibility is sufficient for you. Until it's released at v1.0, RETRO is to be considered an unstable build at all times. I'm only one guy, and I'm just getting started learning MV's code and the differences between it and MZ, and most functions/features are being worked on by repeatedly throwing an MZ plugin at it until it stops throwing a fit. As such the only plugins I'll be able to test RETRO on are the ones I have access to, namely my own and any freely available ones I can get my hands on. Progress will probably be a little slow as I intend to solve any issues a single plugin has with MV until it works, before moving on to the next.

If anyone wants a paid plugin to be compatible with RETRO, someone who legally has that plugin would need to either update their copy of RETRO, or assist me with the appropriate updates. I don't intend to purchase plugins solely to test with RETRO.

On that note... this is not porting any plugin from MZ to MV, that's an edit/update to the plugin itself. While RETRO does read the parameters declared in a plugin to make plugin commands work, it does not write anything to those plugins, and solely acts as a go-between.

Quite a few MZ plugins are(or start off as) ports of MV plugins, so if you like a plugin but it's for MZ, check around to make sure it's not a port of an MV plugin that will work just fine. While my vision for RETRO would allow the MZ version to work just fine, versions written by the original author should always be preferred, as their functionality is guaranteed from the get-go.

Final note: As I said above, I'm just one guy, working on this in my spare time, with only freely-accessible plugins available to me for testing. I have a family and a full time job, so that spare time is pretty sparse, so don't expect fast updates. I appreciate any and all bug reports, feature/plugin suggestions, and assistance with getting paid plugins functional(though that's low priority as I would hope their issues would be the same as one a free one would run into).

I've also been made aware that MZ plugin commands may not function in mobile and web versions of a game, due to how RETRO gets its data. Any issues on that front are intended to be fixed for the v1.0 release.

 

[Restart]

This is a really neat idea!

Now us two need to find a real psycho who's willing to convert scripts into plugins...

 

[Drakkonis]

Version 0.02 update - Most ColorManager functions related to color selection now implemented. Those without MV analogs have been omitted. If a plugin requires any of the omitted functions, I'll add them in. They all route to MV's basic system window skin, so any dynamic runtime skin changes probably won't be supported this way. Testing is required for that part, but it's low priority and I don't have the relevant MV OR MZ plugins at the moment.

Basic scene construction is now enabled, at least the parts that Coelocanth's Item Crafting uses, as that was the first plugin I used to test RETRO(It's pretty much the only MZ plugin I already had on hand that had custom scenes as well as plugin commands, so it was an efficient option). It has a few functions still in place just in case I can get custom help window positioning enabled. If I can't find a clean way to do it, I'll be modifying the modular functions to not reference them. I haven't really looked into it too deeply, as I'm preferring to get as much function working as possible before I start working on the form of functional features.

Now I need to find another MZ-only plugin to work with. I'd appreciate any suggestions, with the caveat that they're freely accessible. In the meantime I'll be making sure all my own stuff works fine. The only reason I didn't START there was because most of mine require a bit of setup to test, and aren't REALLY that complicated as far as the MZ-only functions they use. That and I knew scenes and windows were likely to be an issue, and none of my plugins mess with that.

...I'm tempted to see if VisuStella plugins work, even though they're basically just upgraded ports of Yanfly's... I don't have any of their paid stuff, but I did pick up their free sample project. I've not actually USED any of them though.

 

[Vis_Mage]

This sounds really exciting, especially as someone who's still primary using MV. It can open up a lot of possibilities as devs start moving over to MZ. I look forward to seeing this progress

 

[ShadowDragon]

I use primairy MV, learning JS and create plugins for MV, still, MV is better
than MZ while it deal with minor bugs, and new plugins, but MZ has parts
that is better than MV, and fetures that MV should have.

but while more plugins are made and compability and converted, I do believe,
once MZ is really stable like MV, MZ will take over faster.

but for now, it has it's issues for now, but also some things like the menu
and backbutton I dont like at default. but the look is smoother with the mouse
what MV dont have.

So if this R.E.T.R.O. project becomes stable like FOSSIL will too, or something
that it can be "combined" so it can be used for both MV and MZ, it will be
probably one of the sweetest plugin ever XD

 

[Drakkonis]

Version 0.03 update - Basic Sprite_Gauge functionality implemented. Kinda. In MZ, gauges are their own sprites, where in MV the gauges are simply drawn on the relevant windows directly. So RETRO merely stores the Sprite_Gauge information and then uses MV's native gauge drawing with that information. This means that the gauges will still look like MV gauges and not the MZ ones. There are a few things to note though. RETRO does not currently detect plugin order, so because MV uses a draw function, and MZ uses independent sprites, RETRO doesn't know what plugin is overwriting what, if you have a plugin for each engine that deals with the gauges. To get around that I've included a parameter that controls whether or not MZ's sprite gauges will overwrite MV's gauges. Also, the MZ gauge overwrite function copies the base MV draw function, so if you're using any plugins that change the gauge looks or locations, the overwrite function will have them where vanilla MV sticks them. I'm not sure there's a good way to fix that at the moment, more than likely I'd need to add compatibility patches for each plugin individually. If/when I get the relevant plugins to test, I'll be able to see if there's any kind of universal solution available.
Remember, I'm writing RETRO by finding a plugin that breaks, then fixing those issues. So anything not functional now isn't so much that I've MISSED something, it's that I have yet to test a plugin that needs something I haven't put in yet.
Also fixed a bug I didn't know about from the v0.01 release. It caused the plugin manager to not display ANY of RETRO's information. Since I added a parameter for this release that was obviously a problem, and was in fact how I discovered it. The fix should also make the MZ plugin command register more efficient.

Editing to add updates because of forum double-posting rules.

Version 0.04 update - Help windows can now be positioned correctly with MZ plugins that use MZ's modular functions to build custom scenes. Those scenes will no longer need to be rearranged. This also fixed an issue with custom scenes that didn't even USE the help window.
Implemented MZ's version of textStates. TBH I REALLY don't like how this came to be, as it was a simple copy/paste. Feels a little like cheating, but the MV version is rather simplistic, and the plugin I was testing at the time didn't just call DrawTextEx, which would route through MV's version. Instead it copied the code FROM the MZ function, so all the sub-functions had to be added to make it work. I might try to appease my own perfectionism on that later, but it works, so it stays until I run low on other issues to fix.
Added a function to detect if a function was called by an MZ plugin, an MV plugin, or by MV itself. I really only care if an MZ plugin is making the call or not, but it can detect all 3 options with the aid of another function. Don't think many other people will have need of such a function, but it's there.
Added a few other miscellaneous bits as errors popped up. Mostly minor graphics stuff.

I think I'm gonna stop updating the plugin's help section outside of the version history, as well as the opening post's feature list. Starting to get a little unwieldy. Probably gonna keep it all in a text file in the repository with a link in the post, for those that are interested in following RETRO's progress that closely. I imagine most people are going to be more interested in "Does this work with X plugin?".

 

[ShadowDragon]

most authors that has plugins for MV, and working in MZ, why testing those
MZ plugin if there is a MV version for it?

there are some that made it compitable for both, so I should rather "aim"
for MZ plugins that arent for MV =)

CGMZ_InfiteBalloons is one, he wont make it for MV, so its a nice one.
J_green has a plugin for MZ, but wont make it for MV, also a nice one to test,
pixel movement and some other nice plugins by Ocram for example for MZ,
which isn't for MV, those are probably better tests though

but nice job making it, because I saw some neat plugins for MZ not for MV.
so it can work out nicely if it works outstanding beyond it.

not to mention of " @Restart " that create FOSSIL for MV plugins for MZ,
that arent available or cannot port over because they dont have the MZ version.

so both of you do a pretty nice job for the community

 

[Drakkonis]

most authors that has plugins for MV, and working in MZ, why testing those
MZ plugin if there is a MV version for it?

there are some that made it compitable for both, so I should rather "aim"
for MZ plugins that arent for MV =)

CGMZ_InfiteBalloons is one, he wont make it for MV, so its a nice one.
J_green has a plugin for MZ, but wont make it for MV, also a nice one to test,
pixel movement and some other nice plugins by Ocram for example for MZ,
which isn't for MV, those are probably better tests though

but nice job making it, because I saw some neat plugins for MZ not for MV.
so it can work out nicely if it works outstanding beyond it.

not to mention of " @Restart " that create FOSSIL for MV plugins for MZ,
that arent available or cannot port over because they dont have the MZ version.

so both of you do a pretty nice job for the community

The intent is to allow as close to 100% compatibility as I possibly can, and it's possible that an MZ version of the MV plugin might have MZ-only features that RETRO hasn't had to deal with yet. Since I'm not intimately familiar with all the differences between MV and MZ, I discover the differences by trying to run an MZ plugin and seeing what breaks. Eventually (hopefully soon-ish) I'll get to a point where most plugins will work without further additions/modifications to RETRO.

And I do specify in the original post that if an MV version of a plugin exists, it's better to use that, since compatibility is almost assured, depending on what other plugins you're using, obviously. I mainly suggested trying to test VisuStella's plugins both because of my "discovery" method, but also because you never know if someone decides it would be hilarious to intentionally run the MZ version instead of the MV version. That and VisuStella plugins are mostly seen as MZ ports of Yanfly's plugins, but as far as I can tell, that's only TECHNICALLY true. VisuStella is a TEAM of people, where Yanfly worked alone, I believe. And it seams some functions are either combined or "remixed", where one VS plugin does at least PARTS of what several Yanfly plugins were needed for.

I'm aware of CGMZ and Ocram having their own plugin libraries, it's a logical place to start. I've already started on CGMZ's stuff. I've already had to revamp some of my code twice to accommodate the seemingly odd way CGMZ does things.

As more and more people start switching to MZ, or START with MZ, more and more plugins will be made that only MZ has the tools to handle, leaving MV devs in the dust without a lot of modifications, either to their MV engine or the plugin itself. I see that as in inelegant solution. I originally thought about making all of my plugins compatible without separate versions by detecting what's being used, but when I saw FOSSIL, it allowed me to see that a plugin that acts as an interpreter is possible. RETRO is allowing me to learn MV's code, the differences between it and MZ, and really challenging my knowledge of javascript and programming abilities.

Between all the moments of banging my head against the wall either when something refuses to work, or I discover that my problem was something STUPIDLY simple, I'm actually enjoying the whole thing quite a bit. I get quite a bit of a thrill when another plugin function I've been struggling with finally works.

Honestly some of the slowest parts are learning how these plugins are supposed to be used, since I've already ran through the MZ-only plugins I'd grabbed for my own projects. Seeing as I'm actually EXTREMELY new to the current RPG Maker scene, it was a VERY small list. As in just the CC_ItemCrafting one. Everything else was either an MV plugin that worked just fine, or something I wrote myself. It's kind of hard to make sure that the plugin works fine with RETRO if I'm not aware of how it's meant to be with MZ. A little time consuming, especially for those plugins that require a bit of setup if I want to try to test ALL of their features.

 

[Tea++]

This is pretty cool!

 

[ShadowDragon]

I would say, 100% might be a nice goal, but also probaly (almost) impossible.
even if you get it working for 95%, it's still a nice achievement.

keep up the nice work going though =) many people would love to use it
if most majority of plugins work

 

[Drakkonis]

Version 0.05 Update:
I've overhauled the way RETRO grabs plugin information, and the way MZ plugin commands are used. See the note in the original post.
MZ plugins can now change a sprite image's hue correctly.
Fixed a bug with the sprite gauge implementation that would crash the game when attempting to draw actor gauges after loading a save game. This was caused by my attempting a coding shortcut that doesn't work with class objects. It worked properly until a game was saved and then loaded, hence why it survived this long.

I would say, 100% might be a nice goal, but also probaly (almost) impossible.
even if you get it working for 95%, it's still a nice achievement.

keep up the nice work going though =) many people would love to use it
if most majority of plugins work

Honestly I think even 95% is pushing it. But I aim for the highest I can get. I get RETRO compatible with plugins by trying to run an MZ plugin on MV and seeing what doesn't work. This means that for every plugin I don't know about and/or can't test (mostly paid ones, unless I purchase them for my own projects I'm not going to have them available. I'm not going to buy plugins for the sole purpose of testing on RETRO, that's a waste of money), there's a potential blind spot.

This is pretty cool!

Thanks!

 

[estriole]

first of all... thanks for this great plugin... Lots of ppl ask for me to create MV version of my latest MZ plugin via PM... and i still don't have time to do that... i think i will suggest this plugin instead creating MV version... hope this plugin become stable and work perfectly so i never have to create MV version for every MZ plugin i made in the future... because that's a lot of time honestly... ... great job once again .

 

[OcRam]

Indeed this must be one of the greatest individual plugins ever (with FOSSIL)!

These projects are not easy ones to do, because there are literally thousands of plugins and each of them has been made differently.

I will definetly contribute my part of it, if you allow it.

 

[ShadowDragon]

@OcRam your plugins are awesome, so yo know what you do, while you
own MZ and create plugins for MZ, you can definitely contribute on how
functions works and make it work probably.

While create plugins creators have MZ or might go to MZ, some make it
compatable for both MZ and MV in 1 plugin, even than, there are issues,
sometimes even not possible and a seperate plugin must be made,

but as for for plugin commands, it would be possible to create both in
1 plugin, as for function, that depends differently.

but I saw some pretty nice plugins for MZ, not available for MV, and while
I dont have use for them atm, but when I do start a new game in MV, I might
use this plugin along with some MZ plugins if the terms are not "use if legally owned MZ".
because some use that, specially resources.

but this definitlely because 1 of the most used plugin if used nicely for MV,
and FOSSIL for MZ when really stable for most plugins.

the big question is (no competition though), who would hit 1000+ first
there are more MV users for now, but alot fo to MZ or use both.

keep up the awesome job.

 

[Drakkonis]

Indeed this must be one of the greatest individual plugins ever (with FOSSIL)!

These projects are not easy ones to do, because there are literally thousands of plugins and each of them has been made differently.

I will definetly contribute my part of it, if you allow it.

Definitely not easy, especially as I'm still learning MZ's setup and only just recently got my own copy of MV. But I've learned a LOT about how both engines operate both by trying to make my own plugins work, and trying to develop RETRO. I take it as a challenge not just for my programming chops, which is largely self-taught and thus very amateur level, but also my javascript skills, which ARE self-taught, relying on programming basics and some web tutorials and reading stackexchange questions, and also my understanding of the engine, which is an extension of the first two.

I feel it would be far easier to have a go-between rather than trying to port and/or modify plugins for compatibility, since a plugin's unique functions are self-contained, the only REAL incompatibility is when calling an engine function that either behaves differently between the two or just straight up doesn't exist. This ESPECIALLY important going from MZ to MV, since MV handles quite a few things in the same function, where MZ sticks nearly everything into its own function.

From an efficient programming standpoint, it's very unnecessary and makes the code a little harder to follow if you're just perusing it and not stepping through at runtime. But it makes it a lot easier to make plugins without having to rewrite the whole function just to change one little part in the middle of it. Modular programming like that is a LOT more plugin-friendly and less likely to cause mutually exclusive plugins.

While create plugins creators have MZ or might go to MZ, some make it
compatable for both MZ and MV in 1 plugin, even than, there are issues,
sometimes even not possible and a seperate plugin must be made,

That's actually part of how RETRO came to be. My first plugin requests were from MV users, and I didn't have MV at the time, so I was thinking about making mine compatible with both by checking which engine was being used. But while that would help make my own plugins usable by the larger MV crowd, I only have a few plugins and none are very.... large. I don't even have a clue if anyone is really even using them, especially when there are so many other options. So I figured the best contribution I could make to the community is to build the other half of FOSSIL's bridge. I don't see really any reason why an MV dev would need to port over to MZ just to make use of newer plugins, or be stuck waiting for awesome MV plugins to make their way to MZ either through port, recreation, or convergent development, or why a plugin dev should have to carefully think about which engine their plugin will support, or whether to port or otherwise put in extra effort to make it compatible with both. Or, for people like I was, who wants to fill a request for a user on an engine they don't actually have.

The best outcome is to have either RETRO or FOSSIL, depending on which engine you use, and have access to practically the entirety of the javascript plugin library, and the only truly incompatible plugins being minor fringe cases. Super lofty goal, I know, especially as at this moment, RETRO is developed by a single person with very little free time, amateur programming skills, and only a barely-adequate understanding of the language or engine I'm working with.

 

[Drakkonis]

Version 0.10 is now live, featuring a greatly overhauled plugin command system, (hopefully) mobile-friendly plugin information retrieval, and all sorts of other miscellaneous goodies! This update was developed with the assistance of @OcRam.

 

[Restart]

Very nice!

If you end up needing to set up a framework for plugin-by-plugin compatibility fixes, feel free to use FOSSIL's implementation. If you have a better idea for how to organize individual fixes I'd love to hear it - I figure if we use the same method for formatting compatibility tweaks it'll be easier for other people to submit them.

 

[Drakkonis]

Very nice!

If you end up needing to set up a framework for plugin-by-plugin compatibility fixes, feel free to use FOSSIL's implementation. If you have a better idea for how to organize individual fixes I'd love to hear it - I figure if we use the same method for formatting compatibility tweaks it'll be easier for other people to submit them.

I haven't ran into that much yet. Only one plugin needed a specific fix, and RETRO needed allowances for one plugin author due to the way his code was organized. He doesn't call registerCommand in the global space like 99% of all plugin devs do, he sets a custom function in his core that the others overwrite, so all his commands are registered at a specific time, and all at once, instead of whenever the plugin is loaded. Kinda frustrating because it's so different, but I believe it's intended to make the order of his plugins less important. Or he just wanted to be different for the sake of being different. Or an extra layer to make sure that his core is installed by the user. Not sure, haven't spoken to the guy. lol

 

[xabileug]

how do you use this? im trying this on WDmzPartyChange.js I placed it directly under RETRO.js

 

[ephesus]

QJDoodads.js?

https://qiujiu.itch.io/doodads
https://forums.rpgmakerweb.com/inde...th-my-lighting-plugin-dramatic-shadow.145387/

TypeError: Cannot read property 'length' of undefined
at Window_DoodadsSelectQJ.Window_Command.maxItems (rpg_windows.js:1323)
at Window_DoodadsSelectQJ.Window_Selectable.maxRows (rpg_windows.js:779)
at Window_DoodadsSelectQJ.Window_Selectable.maxTopRow (rpg_windows.js:817)
at Window_DoodadsSelectQJ.Window_Selectable.setTopRow (rpg_windows.js:821)
at Window_DoodadsSelectQJ.Window_Selectable.ensureCursorVisible (rpg_windows.js:1225)
at Window_DoodadsSelectQJ.Window_Selectable.select (rpg_windows.js:795)
at Window_DoodadsSelectQJ.Window_Selectable.reselect (rpg_windows.js:805)
at Window_DoodadsSelectQJ.Window_Selectable.deactivate (rpg_windows.js:789)
at Window_DoodadsSelectQJ.Window_Selectable.initialize (rpg_windows.js:734)
at Window_DoodadsSelectQJ.initialize (QJ-Doodads.js:2676)
[TABLE]
[TR]
[TD]SceneManager.catchException[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1949[/TD]
[TD][/TD]
[/TR]
[TR]
[TD][/TD]

[TD]SceneManager.update[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1910[/TD]
[/TR]
[TR]
[TD][/TD]

[TD]requestAnimationFrame (async)[/TD]
[TD][/TD]

[TD][/TD]
[/TR]
[TR]
[TD][/TD]

[TD]SceneManager.requestUpdate[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1896[/TD]
[/TR]
[TR]
[TD][/TD]

[TD]SceneManager.updateMain[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1988[/TD]
[/TR]
[TR]
[TD][/TD]

[TD]SceneManager.update[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1907[/TD]
[/TR]
[TR]
[TD][/TD]

[TD]requestAnimationFrame (async)[/TD]
[TD][/TD]

[TD][/TD]
[/TR]
[TR]
[TD][/TD]

[TD]SceneManager.requestUpdate[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1896[/TD]
[/TR]
[TR]
[TD][/TD]

[TD]SceneManager.updateMain[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1988[/TD]
[/TR]
[TR]
[TD][/TD]

[TD]SceneManager.update[/TD]
[TD]@[/TD]
[TD]rpg_managers.js:1907[/TD]
[/TR]
[/TABLE]