Difference between revisions of "Talk:Map Format"

From FIFE development wiki
Jump to: navigation, search
m (Cell data: added more details to mapdata additions)
(Cell data)
Line 149: Line 149:
  
 
<grid <attributes?> >
 
<grid <attributes?> >
<cell mc_x="0" mc_y="0" default_cost="1.0" speed_multiplier="1.0" state="0" >
+
<cell mc_x="0" mc_y="0" default_cost="1.0" speed_multiplier="1.0" state="0" blocker_type="3" >
 
<transition x="0" y="0" layer_id="userid" />
 
<transition x="0" y="0" layer_id="userid" />
 
<cost id="userid_1" value="1.0" />
 
<cost id="userid_1" value="1.0" />

Revision as of 15:43, 14 March 2012

Object representation ideas

Important ideas from an irc discussion:

  • Ismarc: I didn't even think about the offsets for grids or anything
  • phoku: hm.. well, i think this field idea could be kept in mind, but could go in the next iteration
  • phoku: objects are (small) lua tables with a visual associated...
  • phoku: in the map file they sit at object grid locations and have pre-formatted script entries and parameters for those
  • phoku: or they are full blown scripts, but that should be seldomly needed
  • phoku: the ingame map mostly keeps track of the visuals(display) and the objects loacation. it will have some hooks to call objects
  • phoku: invisible objects are used for extra storage or other script hooks
  • phoku: later numerical data might be added to the grid, but it's not important now
  • phoku: hmm... map files consist of header: grid geometries used, pointer to data repository, version info ...hm
  • phoku: the tiles for floor and roof
  • phoku: and the objects as described above
  • phoku: hm. well mostly of pointers to objects as described above ...and a position.
  • phoku: ... is that it?
  • Ismarc: the tile for floor and roof and the objects need to specify which grid geometry they are positioned using
  • phoku: woah, okay that is most flexible ... let that be if left out they use the default value
  • Ismarc: yup
  • Ismarc: that puts a lot of power in the modders hands for how the world looks
  • phoku: this contains parts of the map view/model design, too
  • phoku: yes ... indeed
  • phoku: okay. now we ...only... need a detailed design doc made from this
  • Ismarc: now, do we want to allow them to specify how each position in the geometry is numbered, or just use a base system in the engine?
  • Ismarc: like, they say A100, A101, A200. That is then derived as x direction counts up with single digits, y counts up with hundreds, all of which is prefaced by the letter A
  • barra: the map geometry should define the counting, should't it?
  • phoku: i think we should specify that
  • barra: if they want to change it, they could change it in the c++ code; a normal modder wouldn't need that
  • Ismarc: true, it'd just be a matter of designing it large enough so they never feel limited on size of the map

External resources

comments on the map format

  • map-param id (the integer value)

I no longer think having such a field is a good idea; as long as maps are hand-written there is a high probability of authors just ignoring it. In any case the value needs to be unique (or it wouldn't make any sense at all) and this assumption might be true for independent level-makers A and B, but if person C installs levels made by A and B the ids can easily clash... not good. Simply using the map filename as identifier seems better (not by much though).

  • <param type="text" name="NAME">My first map</param>

Why this way instead of <metadata name="..."/>; I guess your way is ~type-safe~, but I have my doubts about validating

<param type="int" name="foo">1</><param type="Point" name="bar">...</>

with a DTD, maybe with a schema?


  • Finally: do we really want xml for storage?

Why? What do we gain compared to writing the map definition in Lua as well?

Skybound 04:13, 24 February 2007 (CET)

  • You're right, I'll remove the ID.
  • Well, I don't see much value in validating? Thing is this is much easier too code... hm. I'm not sure though.
  • I personally think we should stop the endless discussions, and just use what's working, and provide some stability in that.

--phoku 15:51, 24 February 2007 (CET)

Image data

The noise*.xml maps use it; not that I care about those maps and I admit creating image-based maps isn't exactly convenient at this time, but storing the <gid/> tags for any non-trivial map is an inefficient use of storage. Assuming a single tag is 15 Bytes a FO-sized map is:

100*100*15 ~ 146 KB

noise1.png is 6.3 KB

Now, if someone were to write a zip-backend for the VFS...


I do count on that. Though that 146 kb probably don't matter that much. The parsing time could be another issue. But the nice thing with XML is that you can add the stuff without breaking existing maps. Btw. any hopes I could convince you to write a SQLite archetype? :-) phoku


I just created a ticket for the VFS ZIP support. Thomas_34 from the irc channel mentioned that he wants to give it a shot:

--barra 11:27, 1 March 2007 (CET)

Possible notes and grouping support

There are two rather important ideas mentioned the outdated Map editor article that would be a great addition to FIFE IMHO. The first one the the Notes Support that was planned for the editor. I guess this could be done by using the Metadata part of the map format, however I would like to see that every map object itself could contain this metadata, otherwhise you couldn't attach notes. Or we could introduce a specific <note>Your note here</note> tag. I'm not sure if you should be able to attach notes to special tiles on the map but I guess it couldn't hurt; but notes support for objects and especially NPCs would be a really great addition. You should be able to add a number of notes even to a single object to support team work while working on maps.

The second feature I would like to see supported with the map format is what the author of the map editor article called Layers support. I think that having a way to mark objects to represent that they belong together somehow offers some nice possibilities e.g. the engine could turn off the roof layer if you enter a house with your alter ego. To make this possible the engine would need to know that the roof tiles belong together. So maybe introduce a group="xyz" attribute for tiles and objects so you can set the group they belong to? I'm not really happy with the word "group" either, but I hope you get the idea. Another important advantage would be that you could move grouped objects together with the planned map editor. So if you think that the building you just created should be a bit to the south, simply select the group "house_27" and drag it a bit over the map to the place where he thinks it would fit better.

Feedback please :-)

--barra 09:52, 1 March 2007 (CET)

I am pretty sure both can be done already, for two reasons.

The notes section can be implemented with metadata as you have realized already. Especially the editor could claim the metadata names "_note" and display it as a note on Map, Elevation, Layer and any Objects. I think these are all relevant parts. Hm. Maybe some stuff in the archetypes needs this, too?

Grouping should be done with layers itself. But you are right there is a deficiency that a layer currently can not be offset to another layer in terms of grid cells. Though this can also be implemented in the map editor with metadata (_reflayer and _gridoffset) and the map editor can then have "merge down" feature like known from image editors (gimp).

So for now, I'll vote against adding this as separate tags and sections. These can be implemneted already seen from a map editor point of view.

Also the XML map loader ignores unknown tags, so you also can add them in the map files, if one wishes to do so.

Also please note, that the metadata section should be used for these "work in progress", "obscure" and/or "might change later" features, so that they don't litter the map format =)

--phoku 14:48, 1 March 2007 (CET)

Problems with object layer...

I split my map into 4 layers - 3 for tiles (#0,#1 and #2; RECTANGULAR custom geometry) and one for objects (#3; HEXAGONAL default FO object geometry). I planned to add some more object layers for roof etc. - but after placing my tiles and starting to work on the object layer, I figured out that FIFE always uses layer #1 for the object grid. (took me some time.. -.-).

So if I´m trying to get the coordinates (new tool with "c"-key binding) of my hex-based object layer #3, I get the coordinates of rectangular based layer #1.

Is there any way to tell FIFE which layer is the object layer? And if so - how much time would this feature need to be implemented?

There is a kind of an ugly workaround:

  • delete all additional tile layers temporarly
  • load FIFE and place your objects
  • repaste your tile layers in the map file

But as I said beforehand - this is very ugly. So please help me :o)

I guess the simplest solution would be to define the object layer in the metadata of the map:

 <map>	
     <metadata>
	<param name="_START_ELEVATION" type="id">0</param>
	<param name="_OBJECT_LAYER" type="id">3</param>
     </metadata>
 </map>
 

--chewie 12:52, 27 April 2007 (CEST)


Additions to map format

Cell data

The current rewrite of the Pathfinder introduces data which has to be stored in the map file:

  1. cell default cost multiplier
  2. cell custom costs (id, value); set by the client / FIFedit
  3. cell speed multiplier
  4. transition data (connecting two cells like a portal)
  5. cell states (for field of view implementation)

As especially #2 involves an unknown amount of data (depends solely on the client), I'd suggest a separate section in each layer and use a structure like this:

<layer>
	<instances>
		....
	</instances>
 
	<grid <attributes?> >
		<cell mc_x="0" mc_y="0" default_cost="1.0" speed_multiplier="1.0" state="0" blocker_type="3" >
			<transition x="0" y="0" layer_id="userid" />
			<cost id="userid_1" value="1.0" />
			<cost id="userid_2" value="1.0" />
			<cost id="userid_3" value="1.0" />
			<cost id="userid_4" value="1.0" />
		</cell>
	</grid>
</layer>

--chewie 21:50, 14 March 2012 (CET)