PDA

View Full Version : Objects Table Standard


Centauri Soldier
06-29-2009, 12:27 PM
I have noticed that many plugins and scripts make use of a table that references all of the AMS objects. The problem with this is that the objects of AMS change over time and they change if other object plugins are added to a user's project by use of an object plugin. e.g. Worm's framework code becomes outdated when IR adds an object to AMS because his objects table does not contain the new objects. Now, since the code is offered openly on the forum, it is a simple matter of adding the new object(s) to your script file on your PC and the code works again. But what if Worm had created a plugin for the framework...it sure would be nice to have a standard in that case.

I thought it might be wise to suggest a standard for that table name so all plugins that use that table could reference the same table. That table could then be placed either in a plugin itself (that has its own thread and can be updated) or simply a script file and that, as well, could be updated easily without having to update every single plugin that makes use of it.

We could also create an optional script that will determine the active objects in a user's project and add any unlisted objects (added from that user's object plugins for instance) into the objects table that is already in memory (during runtime of course).

If we all use the same universal code standard for this I think our plugins and scripts would work better with one another.

I propose we use a name like

tAMSUniversalObjectTypes

for the universal table name.

What do you guys think? Will this work or have I overlooked a problem that is impassible?

MicroByte
06-29-2009, 03:17 PM
soz, but i disagree, i like my scripts and plugins to be completely self reliant, also any tables you add in a external script (like the object one) should be local to that script as information is passed back through the function args and returns, plus "unlocalized variables and table references are processed 30% slower than local variables" (from lua gems) and can also cause conflicts/errors if a variable of the same name is used elsewhere in the script.

but that's just my penny's worth

Centauri Soldier
06-29-2009, 03:26 PM
..."unlocalized variables and table references are processed 30% slower than local variables"...

Well, I didn't know that. If that is indeed the case, then this would be a very bad idea. I wasn't aware of the noted impact of globals versus locals.

MicroByte
06-29-2009, 03:33 PM
read the online version of Lua Gems (http://www.lua.org/gems/), the Lua Performance Tips (http://www.lua.org/gems/sample.pdf) section is a very good read.

Imagine Programming
06-29-2009, 03:34 PM
I also disagree, basicly the same reasons as MycroByte's.

Centauri Soldier
06-29-2009, 03:37 PM
Thanks for the links...this will help me understand your reasoning a little more.

Centauri Soldier
06-30-2009, 02:51 AM
I have delved into the references you posted and I am amazed at the inefficiency at which I currently program. Once again, thank you for the info, using these methods will help a great deal in improving my code.

ShadowUK
07-28-2009, 11:15 AM
It really doesn't make that much of a difference. It's like omitting a doctype in HTML or using short-tags in PHP. Noone is still on a Pentium II processer. At least, I hope not. :rolleyes