Making adventure map objects more configurable

International board Development
#21

Not sure if I’d need to create new topic or bumping this one is fine, but anyway. Currently I’m look via adventure map objects handling code and see there is few things that incomplete: cartographers need don’t work as non-unique objects, “visited” and “owned” not displayed for all objects where it’s needed. Though it’s possible to just fix those in code, but it’s result in code duplication that looks bad. So I decide to ask few things.

First of all is it important to stick to behaviour of vanilla H3? E.g cartographers for don’t have “visited” hover text in vanilla and some objects that can be owned don’t have “owned” hower text. Personally I think that what I see it’s would be useful to add “owned by” in status for all objects that can be owned.

…

Also at moment there is few separate handlers “onceVisitable”, “oncePerHero”, “oncePerWeek” used by rewardable objects. Still those handlers can’t be used by special objects like cartographers and keymasters and objects that use “onceVisitable” still shouldn’t share this information for other players.

Based on this I think what if each object in JSON would have few more properties like:

  • (bool) “isUnique”. Set to “false” for keymasters, cartographers and any other objects that once visited/paid you can no longer use any other objects of same type/subtype.
  • (bool) “canBeOwned”. Set to “true” for mines, dwellings, lighthouse, shipyards, border gates, etc (?). Possible this should also enable "Owned by " hower text for all such buildings.
  • (string) “visitLimit”: onceVisitable, oncePerPlayer, oncePerHero, oncePerWeek, etc. Those might be moved to option and in same time rewardable objects might get different “handler”.
  • (bool) “visitVisibility”. At moment all rewardable objects like Warrior’s Tomb are marked as visible for every player while they shouldn’t (there is note in code). So VCMI might not only fix this, but also implement an option that make certain object marked as visited on adventure map for every player. Shouldn’t be needed for vanilla objects, but might be useful for mods.
  • Also thinking there might be some property that allow to set guards to certain object…
    Of course it’s just my thoughts and properties, names and options might be different, but I think something like that would help to finish implementation of current objects and also add a bit more modability.
#22

I think we first should reach working state for all objects from summer, as object rewrite is clearly not complete and includes a number of bugs or missing options.

#23

Sounds reasonable. However specifically about cartographers this is a bit tricky - if another player has activated Shroud of Darkness (one-use version on map) should we un-mark cartographers as visited?

Yes as long as this works only for players that see interaction, not globally for everyone. H3 objects also may use this - e.g. Windmill or Skeleton (object that don’t have yes/no confirmation dialog).

Although as Warmonger said I’d suggest going through known bugs first. Specifically these:
bugs.vcmi.eu/view.php?id=1912
bugs.vcmi.eu/view.php?id=1940 (and similar bugs for some other objects)

Also, I think I had some unfinished (and unpushed) work on this, specifically - on loading some objects from config. I’ll check in what’s state this branch now and push it in repo before it gets lost competely.

#24

In vanilla you can only buy each type of map once. Though it’s would be interesting if it’s will be possible to mod a different cartographer with different rules.

Will try to find out. Actually those objects without messages is likely most annoying problem in game at moment. Still there is many quite primitive things missing and at moment they do cause code duplication. Is this okay for now?

Unfortunately I’m not professional C++ programmer so only thing I worry about it’s not to craft tons of useless code if there is better solution possible. :blush:

Would be great to see it even if it’s will be in some separate branch.

#25

Other idea that should make both modding of objects and reading of configuration easier. Why not just split current code into “visitLimit” (once, oncePerPlayer, oncePerHero) and “resetPeriodicity” (never, oncePerDay, oncePerWeek, oncePerMonth, eachFriday, etc) so they would be independent options?

#26

Ivan, can you say me something?

Now for boat object we have

94 	"boat" : { 
95 		"index" :8, 
96 		"handler": "boat", 
97 		"base" : { 
98 			"base" : { 
99 				"visitableFrom" :  "+++", "+-+", "+++" ], 
100 				"mask" :  "VVV", "VAV" ] 
101 			} 
102 		}, 
103 		"types" : { 
104 			"evil" : { "index" : 0,	"rmg" : { "mapLimit" : 64 } }, 
105 			"good" : { "index" : 1, "rmg" : { "mapLimit" : 64 } }, 
106 			"neutral" : { "index" : 2, "rmg" : { "mapLimit" : 64 } }, 
107 		} 
108 	},

As I looked into sources, boats are handled still like they was (my commits for boats modding were rejected in summer, but still no movement in this theme).

Can I for future use mod boats already?
Like in section “objects” add json, where will have

94 	"boat" : { 
95  		"types" : { 
104 			"myNewCoolBoat" : { 	
"rmg" : { "mapLimit" : 64 },
 "templates":{"mynew":{"animation":"newcool.def","allowedTerrains":"sea"}} }, 

107 		} 
108 	},

and after boats modding is finished, that will work?

#27

Together with previos question on boats, next question had arisen.

I wanted to add bridges to map objects.
I created sub-object of

	"core:canyon" : {
	"handler": "generic",
		"types" : {
			"bridges01" : {
				"name" : "Bridge",
"rmg":{
					"value"		: 100,
					"rarity"	: 50},
			"templates" : {
				
								"bridge01" : { "animation" : "decors/bridges/bridge01.def", 
					"visitableFrom" :  "+++", "+++", "+++" ], 
					"mask" : "BBBBB","VVVVV","BBBBB"],
					"zIndex":-1
					},

}
}

In WIKI there is field “zIndex” that affects overlay. I looked into source code, it loads on start.
By the way, json scheme writes “unknown entry found: zIndex”.
On map bridge still hides hero under him instead of be under hero (as it is like only decoration on earth).
Is there is no way to make def zIndex lesser than hero’s?

#28

Not 100% sure about most recent git, but I feel like there was issues with that even with default H3 assets so it’s maybe just a bugs.

#29

I think next big thing I’m going to do is more configuration options for map objects.

I’m currently tried to make list of incorrect visit sounds and clearly find out that they should not be set in code at all as it’s super hard to change them this way.

I’ll suggest new JSON options quite soon.

#30

Seems you got no time for objects sound configuration:-)
Time comes to stage, when i think about adding battlefields filenames to objects JSON.
We got here need to input path to battlefield backgrounds, to think about adding obstactles confguration for each object configuration section, and (arbitrary) for sound files serving as music background for battlefields.

How about adding section to each object like:

"battlefieldProperties" : 
  {
     "battlefield" :  "coolmod/background1" , "coolmod/background2"  ],
     "obstacles":
      
       {
		"width" : 2,
		"height" : 1,
		"blockedTiles" :  [0, 1],
		"defname" : "ObDino1.def",
		"unknown" : 1
        },
     ]
     "absoluteObstacles" : 
      
        {
             	"width" : 300,
		"height" : 214,
		"blockedTiles" :  [59, 60, 74, 75, 76, 93, 94, 95, 111, 112],
		"defname" : "ObMCL00.pcx"
         },
      "music" :  "coolmod/battle1", "coolmod/battle2"  ]
     ]
}

Battlefield and music will be taken randomly (if there is more than one val in array).
Obstacles can be programmed in future, because now there are no obstacles in banks, on ship etc., and this difficult coding can be postponed.
So if object has set section “battlefieldProperties”, this section information will be used.
If object don’t have this section, than battlefields/obstacles will be taken depending on terrain.
Bonus of this approach:

  1. There is no need to set something for passive objects
  2. Each bank and creature dwelling will have possibility to have custom battle background/music.
  3. There is no need to enter new code for existing battlefields functioning (only to move special terrain patches battlefields to their JSON config. No need to add new mod.json sections (like “factions”, “heroClasses”, etc. Later this structure can be inputed directly to terrain config.

For example, boats will get possibility to have custom battlefields when fighting with neutrals or under attack from bank.
Terrain patches also will have custom battlefields.
For standard terrain specific battlefields only need for random choosing of current battlefield from array of terrain battlefields is welcome.

#31

UPD About configurable battlefields.
Someone earlier said he want to see battlefield for forest, when battle is near trees.
I propose t allow user to assign battlefields properties also to decorative objects (like trees, rock, river deltas, etc).
I propose this algoritm.

  1. When battle is initiated, VCMI first will check, if hero is visiting object. If yes, then it checks if object have battlefield assigned. If yes, battlefield is taken from object.
  2. If there is terrain patch under attacked position, than special battlefields for patches will be used (taken from battlefield configuration from terrain patches).
  3. If object dont have battlefield properties, VCMI will in random direction check +1 squares around him (8 squares). If there is passive object like trees (without “A” entering square in “mask”) and it has battlefield configured, than it’s will be taken and used as background.
  4. If none is configured, that terrain battlefields will be taken (from array of terrain battlefields names, choosen randomly).
#32

Not sure about #3 (having battlefields for landscape object is a new idea), but certainly for armed objects it’s a way to go.

First we need to have custom battlefields anywhere and then we can think of interesting mechanics and practical configuration.

#33

Didn’t have time for anything for a while, but now I’m back. Though currently I’m decide to work on pathfinding and movement rework first because it’s what more important to make VCMI playable (proper implementation on fly / water walk require some redesign of current code) and it’s code I already familiar with. If I manage to do that then I’ll certainly go for objects because there is more flexibility needed for all kind of things; not just sound.

BTW I like suggestion about battlefields backgrounds, but main issue there is art as always.

#34

There is a mod for ERA with additional battlefields present.
Also there are many resources with sprites from games (including battlefields), that easily can be converted to HMM3.
For example, some battlefields can be taken from RPG Maker graphs assets.
First possibility needs to be made, than content will arise :mrgreen:

#35

That ERA mod with 50+ battlefields is well enough. It’s in fact one of core mods and it’s where this whole idea came from.