[http://sourceforge.net/p/ufoai/bugs/3446 Item 3446] imported from sourceforge.net tracker on 2013-01-28 20:10:24

DarkRain, as you already solved the "Could not find ..." issue on map loading, maybe you can help here, too?

It is possible to use map tiles from other maps by giving the full path in the assembly instructions. In this case the tile descriptor and the .bsp file are loaded from the given path. An example for this is the +rescue map, which uses the tiles from +ufocrash. This works fine so far.


However, using the *rm_drop* or *rm_ufo* cvar does not work.

Extending a map by using e.g.

africa/af_craft_drop_firebird "1 1"

works fine, but

*rm_drop africa/af_craft_drop_firebird "1 1"

gives

ERROR: Could not find tile: '+craft_drop_firebird'

It would be nice if we could get this working, as it would give a bunch of additional possibilities.
===== Comments Ported from Sourceforge =====

====== tlh2000 (2012-12-25 19:55:08.760000) ======

may i suggest using symlink in our virtual filesystem for features like these? (cross-assembly-tile-usage that is)
====== darkrainx (2012-12-25 20:40:42.996000) ======

(Huh? SF seems to have eaten my previous comment...)
I think ShipIt also wants to reuse the tile definitions, but that would require extending the ump format, ShipIt any ideas?
====== shipit (2012-12-26 09:09:11.836000) ======

Well, if possible, it should use the tile definition from the source, just as it works for the common tiles.
====== darkrainx (2012-12-27 00:28:19.845000) ======

If reusing the tile definitions is needed then the ump format will have to be extended with some way to tell the parser the full path of the tile referenced in the cvar (something like *some_cvar@some_rma/prefix_ some_rma/prefix_tile or something like that, you tell me I'm not much of a mapper) but that would mean you have to inherit __all__ craft tiles of that type from the rma you are extending
====== shipit (2012-12-27 07:48:10.686000) ======

*rm_drop africa/af_craft_drop_firebird "1 1"

should read the tile descriptor for the needed dropship (the dropship type given by the cvar) from africa.ump and load the af_craft_drop_*.bsp. As you said, in this case, no matter which dropship it is, it is taken from the given path. That is how it should work.


====== darkrainx (2012-12-27 20:56:23.777000) ======

The problem with that is the need to guess the path from the default value, which may not be a craft tile at all (I don't have a reason to doubt that it is the case in all umps currently, but in my experience assuming things only leads to problems)
Incidentally while I'm at it, do you think someone will ever have the need to use more than one 'extends' in a single ump? I've already found that extending an ump that already extends other one may cause problems that range form annoying to serious, and I've been thinking of forbidding more than one extension per ump
====== shipit (2012-12-28 09:12:16.921000) ======

*The problem with that is the need to guess the path from the default value, which may not be a craft tile at all (I don't have a reason to doubt that it is the case in all umps currently, but in my experience assuming things only leads to problems)*

Sorry, but I don´t get the point here.

*Incidentally while I'm at it, do you think someone will ever have the need to use more than one 'extends' in a single ump? I've already found that extending an ump that already extends other one may cause problems that range form annoying to serious, and I've been thinking of forbidding more than one extension per ump*

My initial idea would not require more than one ´extends´ in a single .ump, and it would not require a chain of ´extends´ (where an extended .ump refers to another extended .ump).
====== shipit (2012-12-28 11:09:36.002000) ======

I tried to kinda sort things out here: http://ufoai.org/wiki/Talk:Mapping/Random_map_assembly
====== shipit (2012-12-30 08:21:50.827000) ======

There might be another problem. When tilesets were implemented, it seems nobody thought about the possibility of map extensions. So a tileset doesnt have a prefix nor another way to specify its location. If I write a tileset into the assembly list of an extended map, how does the algo know where to take it from?
====== darkrainx (2012-12-30 15:02:34.933000) ======

First the problem wit guessing the path: lets take your example,

~~~~
*rm_drop africa/af_craft_drop_firebird "1 1"
~~~~
I know that rm_drop is supposed to store the name of a craft prefixed with '+' and the full tile name can be obtained by replacing the '+' with the base path, but how do I guess the base path form the default tile?
Finding the directory is trivial as I only need to find the last '/' in the path (so I have the 'africa/' part so far), but how do I know if the tile name has a prefix? Not all RMAs use prefixes (+hills comes to mind, not the only one)
Some might say search for 'craft_', but
1) how do I know the mapper didn't decide to make a +craft theme and prefix all tiles with 'craft_' (say I get *rm_drop craft/craft_craft_drop_firebird "1 1")
2) the default tile might not to be a craft tile, it might be something like: *rm_drop africa/af_default_start "1 1"
3) when/if aircraft becomes scriptable there might be aircraft with non-conventional names, for example a modder might create a new craft and give me: *rm_drop africa/af_the_mighty_executioner "1 1"
I know that you guys will always make sane decisions with respect to rma/tile/craft names, but assuming that your sanity extends to all possible modders out there is asking for trouble.

Second tilesets: they don't need a path they are just collections of tile names, it's the tiles that form the tileset that need a path, but the parser takes care of that, 'expanding' the '+' to the full path of the tiles when it is reading an inherited ump, so they should work fine (but nobody has tested it AFAIK).
In fact the parser expands all tiles in an inherited ump to full path, that's the reason you need to type the full path to them, while building the list of tiles for that map normally they would be stored with their given id (say +craft_drop_firebird) but when reading from an inherited ump they are stored with their full path (like africa/af_craft_drop_firebird), the same goes for the list of tiles in a tileset.
====== shipit (2012-12-30 17:13:52.692000) ======

A craft tile will always be named

prefix_craft_drop_nameofdropship
prefix_craft_ufo_nameofufo
prefix_craft_crash_nameofcraft

In case somebody fails the naming conventions, the application should crash and destroy his HD without further notice.

I will check/fix our maps accordingly.
====== tlh2000 (2012-12-30 18:12:37.831000) ======

of course they will - but DarkRain's point is, that the cvar can be anything. And we should not work against it. What do you guys have against my symlink idea?

link maps/theme/prefix_craft_drop_name maps/othertheme/otherthemeprefix_craft_drop_name

or did i miss the point here?