Difference between revisions of "Talk:Map format"

Latest revision as of 16:41, 12 November 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.

[Done]--AVS (talk) 11:43, 25 August 2015 (CEST)

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)

What needs to be changed here is team configuration UI - h3maped UI looks like minesweeper. Simple dropdown list would be notable improvement over H3 grid of radiobuttons.

dropdown list of what?--AVS (talk) 11:45, 25 August 2015 (CEST)

of teams. Like team selection column here: http://smg.photobucket.com/user/Teelo/media/trnagalobby.png.html Ivan (talk) 19:59, 25 August 2015 (CEST)

How this will be represented internally doesn't matter much - map should be edited via editor, not via notepad. But actually Warmonger's version does looks better (although I'd rather use player color names instead of numbers). For me team is a separate entity from player so it should be defined separately. Ivan (talk) 21:54, 24 August 2015 (CEST)

Warmonger's version with string colour names accepted.--AVS (talk) 17:41, 12 November 2015 (CET)

Player information format

"randomFaction" - needed? this sounds like one of those h3m weird flags. IMO there is no need for per-map settings for this option. In single player you can simply restart till "right" faction and in multiplayer this sounds more like RMG option or global game option. Same goes to random hero option

These are thing I`m researching now. They are somewhat tricky. These flags informs engine is it actually possible for player to play random faction or select random hero. I`ll update section soon.--AVS (talk) 11:42, 25 August 2015 (CEST)

"canXPlay" - I'd rather turn this into enumeration "AIonly / PlayerOrAI / PlayerOnly" if only to avoid weird situations when both canAIPlay & canHumanPlay are set to false.

if both canAIPlay and canHumanPlay set to false, player is unplayable and this player entry is ommited.--AVS (talk) 11:42, 25 August 2015 (CEST)

then why this entry is needed in map format? What if there is town or hero that belongs to this player? Ivan (talk) 20:06, 25 August 2015 (CEST)

OK, lets switch to enum.--AVS (talk) 04:47, 26 August 2015 (CEST)

"mainHeroX" - I think these are present in H3M only to make hero selector work with predefined heroes. IMO better solution would be to place predefined heroes in header or load this section of map once advanced options are activated.

I have no plans for now to add "extended header" to json, so predefined heroes will be in header at least in json anyway. So I`ll remove that fields. --AVS (talk) 11:42, 25 August 2015 (CEST)

Actually this needs to be rechecked - what if hero with custom name was placed on map? In this case name can be configured from both predefined heroes dialog and from map object. And to get name from map object entire map must be loaded. *possibly* better solution would be to place all data in predefined heroes section even for heroes already placed on map but there may be side effects so not sure if this is safe. Ivan (talk) 20:06, 25 August 2015 (CEST)

there is placedHeroes field for that.--AVS (talk) 04:47, 26 August 2015 (CEST)

Ivan (talk) 21:54, 24 August 2015 (CEST)

Object unique identifier

Just a suggestion - perhaps it is better to turn objects array into structure thus giving each object a unique id? Such unique id could be autogenerated for example <object_type_name_###> where ### is a simple auto-incremental counter to guarantee its uniquness. (or any other method that would result in a unique string) Ivan (talk) 21:54, 24 August 2015 (CEST)

Interesting:) should subtype be included? How long can that id be? There may be problem with mods with looong ids, such as "Axolotl Creatures Pack by GILU" (with submods)--AVS (talk) 12:02, 25 August 2015 (CEST)

And problem is not length but format - actually mod id can contain anything - it is directory name, object id may become smth like modname ":" objectType "::" modname ":" objectSubtype "::" unique_id. I don`t like this ...--AVS (talk) 12:17, 25 August 2015 (CEST)

This ID is needed only to generate unique string representing this object. Simple "object_###" will work just as well and so will GUID but this will be less readable. Theoretically this name can be later exposed to scripting and made user-editable (in map editor) so script may refer not to "object at tile X, Y" or to object with GUID XX-YY-ZZ but to nice name like "evil_wizard_castle". Although perhaps some sort of GUID can actually be used here - guaranteed to be unique, fixed length, easy to generate. Should work fine except for lack of readability (not necessary for internal ID). Ivan (talk) 20:16, 25 August 2015 (CEST)

We may add "description" field for map objects in future to be used in gui, but we should not change unique identifiers - only invariant ID is useful.--AVS (talk) 05:02, 26 August 2015 (CEST)