Adding dynamic [terrain_type] or [terrain]->[modifications]

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderators: Forum Moderators, Developers

Forum rules
Before posting a new idea, you must read the following:

Adding dynamic [terrain_type] or [terrain]->[modifications]

Postby shrieker1 » September 3rd, 2017, 11:31 am


There is actually two possible engine side terrain changes that would simplify implementing following idea

I'm trying to make recruitment work dynamically in a location that is selected based on player actions. Player can change locations using menu_item to make nearly any location possible recruit location. I was wondering how much changes wesnoth would require to allow this use standard recruit menu. For my case it would require more than just this change. But I tough this change might be useful to other use cases too.

For many solutions limiting requirement is that it must work from MP era tag without requiring players to download the addon. Following lists possible solution that I came up

  1. Add [terrain_type] tag clones for all possible recruit_to terrains
  2. Make it possible for lua code to access and add [terrain_type] entries dynamically
  3. Support per hex modifications to [terrain_type]
  4. Use custom menu_item for recruitment (like it is currently done)

1. Add [terrain_type] tag clones for all possible recruit_to terrains

This solution would "work" with stable wesnoth. Problems are any new or addon terrain_types. Any future changes to terrain_types in mainline.

+ It works in stable wesnoth
- Error prone with long list of copied terrain types
- Won't support custom terrain types from other addons without manually adding them
- Later modifications to mainline or other addons require compatible changes.

2. Make it possible for lua code to access and add [terrain_type] entries dynamically

This sounds like usable solution If dynamic modification would be allowed any time in the scenario it would allow era code to add dynamic terrain_type when adding a new recruitable location.

+ Lua code can handle any terrain codes that exists in the map
+ Likely requires minimal changes to engine because most of changes would be just lua API and code to refrest terrain_type list for running scenario
(-) It won't work for wml only use case (not an issue for me but it might be for some people)

3. Support per hex modifications to [terrain_type]

This would make it very simple to modify any hex matching location filter with required change. Too bad I feel this will likely require large engine changes to support per hex modifications. But this rework would make it easy to add per hex [variables] that would be useful for many usecases. I haven't looked into c++ terrain handling code to figure out how easily this could be actually implemented but I feel this needs quite some work.

The map handling code would need to support code for per hex terrain_type modifications. That would require each hex store modified terrain attributes. The terrain information lookup code would need to be changed to use location as a key. wesnoth.get_terrain_info would then fetch base terrain_type information and apply per hex modifications before returning the information to engine, rendered or scenario code.

Saves would require minor addition with ability to store per hex information.
Code: Select all

Then scenario or era code could simple apply and remove modifications using same code as unit modifications using [object] tag.

+ Makes scenario interface simple and consistent with unit modifications
+ Easy to add per hex [variables] that I see as an useful addition
- Very likely requires a lot c++ changes (I haven't looked the code)
Posts: 21
Joined: August 7th, 2017, 5:53 pm

Return to Ideas

Who is online

Users browsing this forum: Yandex [Bot] and 4 guests