Talk:Resources

I have an even better suggestion: rename it from .zip to something unique (whilst keeping it still compressed as a zip) and have it open with MTA:SA. MTA can then automatically copy everything to the right directories without the user having to specify. MTA:SA has a lot of folders, so this would ease any confusion as to where to put things. - JonChappell 15:37, 26 December 2006 (CST)

Thats a good idea. I'll add it to the page. eAi 06:41, 27 December 2006 (CST)

I don't know if this has been addressed before, but is there a good way for add-on resources to get information from game mode resources? Currently you can call the add-on's exported functions, but that is not practical for most end-users. Having the data stored in a config seems like the ideal solution, but how can add-on scripts know which config to read from? It would be nice to have some standardized way of doing this. --Erorr404 04:06, 11 June 2007 (CDT)

About resources

There are some still unanswered questions:

• How does the serverside element tree look like with multiple maps from multiple resources? If all elements are simply getting merged into one parent map tag, scripters can't know what resource does a certain element belong to. Maybe something like

<root>
   <resource name="myresource">
      <map name="map1">...</map>
      <map name="map2">...</map>
   </resource>
</root>

would make more sense now, maybe with getRootElement() taking an optional argument to return the root element, a resource's root element, or a map's.

• What is going to be the final specification? We're using the old spec from this page, because the new one is not functional.

• Shouldn't included resources know what resource included them? There seems to be a getIncludedResources(), but we still lack something like getParentResource().

• What map functions are deprecated? Most were made when only one map could be loaded at the same time, and are probably useless now.

Also, all resource function pages need syntax.

--jbeta 04:04, 4 March 2007 (CST)