Difference between revisions of "Talk:Map format"

From VCMI Project Wiki
Jump to: navigation, search
(Terrain)
(Teams: new section)
Line 46: Line 46:
  
 
: I'd rather avoid introducing yet another config format if only to reduce amount of code we need to support (I know that CSV format is trivial but still). If speed is critical here (loading 10k+ of tiles may do that) them we may consider binary format but I'd rather keep this as a last resort.
 
: I'd rather avoid introducing yet another config format if only to reduce amount of code we need to support (I know that CSV format is trivial but still). If speed is critical here (loading 10k+ of tiles may do that) them we may consider binary format but I'd rather keep this as a last resort.
 +
 +
== Teams ==
 +
 +
How about configuring teams globally, like
 +
"teams" : [[1, 2, 3], [4, 5]]
 +
 +
This way you could see them at glance. Team editiing may become easier as well (one tab).
 +
 +
I was thinking about arbitrary teams in random maps, as above. These may be not directly related, bt would be good to keep both formats consient.
 +
--[[User:Warmonger|Warmonger]] ([[User talk:Warmonger|talk]]) 19:50, 24 August 2015 (CEST)

Revision as of 17:50, 24 August 2015

Versioning

Right now there are three fields that describe map version: format version, format revision, engine version.

Suggestion: remove redundant engine version & possibly - rename version+revision to major version + minor version (more logical names from my point of view)

Done --AVS (talk) 03:36, 3 July 2015 (CEST)

Level header

1) Any actual reason to split map objects by level? Perhaps keep them in one file instead of per-level?

Just a bit smaller file, no level coordinate. --AVS (talk) 03:13, 3 July 2015 (CEST)

2) Do we need to keep reference to json file with terrain? Maybe use same name as level, e.g. "surface.json" to avoid inconsistencies in naming?

We are already using this type of indirection in mod configs, kinda standard. --AVS (talk) 03:13, 3 July 2015 (CEST)
That's mostly because mods have complex filesystem and may add multiple objects or modify existing. If we were to put (for example) all data associated with one object like creature into one archive like we're going with maps I would prefer to use fixed names within that archive as well. So IMO there is no need for configurable names within map archive. Ivan (talk) 21:03, 3 July 2015 (CEST)

3) "depth" - rename to generic "index"? After all, maps with more are not necessarily stacked on top of each other - they can represent different parts of world as well.

fixed here, already "index" in map editor --AVS (talk) 03:13, 3 July 2015 (CEST)

Terrain

[F][flags as uint8] Perhaps they should be coded as part of terrain/road/river descriptions?

[Done]--AVS (talk) 09:59, 27 July 2015 (CEST)

E.g.

_ no rotation (use space instead?)
- left-right flip
| top-bottom flip
+ both directions

Example: wt34+pc3-
Nice idea, but there are some other flag bits except rotation. "coastal bit" and may few more. Should we use them? --AVS (talk) 03:27, 3 July 2015 (CEST)
IIRC there is also "favorable winds" flag. Ideally I'd rather remove them entirely - from map format as well as from engine. Coastal tile is tile that neighbours water tile. Not one that has some flag that may or may not be set by editor. Ivan (talk) 21:10, 3 July 2015 (CEST)
So engine should set coastal flag on map load?
If necessary. I'd rather add some sort of method "isTileCoastal" that will check neighbours for water and will be called only when needed. Ivan (talk) 08:53, 4 July 2015 (CEST)

Othervice looks great. And nice idea with using logical expressions for allowed objects. Haven't thought about it before :)

Ivan (talk) 19:37, 2 July 2015 (CEST)

  • Also csv for 2d terrain array is more suitable than json. How about that? --AVS (talk) 03:29, 3 July 2015 (CEST)
I'd rather avoid introducing yet another config format if only to reduce amount of code we need to support (I know that CSV format is trivial but still). If speed is critical here (loading 10k+ of tiles may do that) them we may consider binary format but I'd rather keep this as a last resort.

Teams

How about configuring teams globally, like "teams" : [[1, 2, 3], [4, 5]]

This way you could see them at glance. Team editiing may become easier as well (one tab).

I was thinking about arbitrary teams in random maps, as above. These may be not directly related, bt would be good to keep both formats consient. --Warmonger (talk) 19:50, 24 August 2015 (CEST)