Currently, there is just one "active_unit_path" variable in Game.gd, which causes some trouble when this variable gets changed while a unit is currently moving, e,g when selecting and moving a different unit or ending a turn meanwhile.
Thus, I think it would be good to move the path that a unit should walk onto into the unit itself. This way, there should be no "collisions" while having multiple units walking (if that'll be a thing) or doing something else which causes active_unit_path to overwrite be overwritten while a unit is still moving.

when I was playing a little bit with the lobby I found by quickly spamming on the campaign card that we can let the card keep their expanded size:

Sides shall be able to recruit units.

For this we need factions a side can choose from.
these factions define the leader and recruitable units of a side.

I am thinking a RFaction class, extending Resource.
these would contain all information needed and would be loaded into a side.

There was a fair amount of discussion about this on Discord the other day, but this prototype(and the eventual full implementation, if that happens) really needs to settle on the project license sooner rather than later.

For art/music, it's fairly straight forward: anything taken from Wesnoth 1 remains under the same license, whether it's the GNU GPL v2+ or CC BY-SA 4.0. Anything new is under the CC BY-SA 4.0.

For code though, it becomes more complicated, but some things that need to be considered are:

• Linking to non-free libraries, such as the SteamWorks SDK or Discord's Rich Presence.
• The license of Godot add-ons, such as the YAML parser.
• Any modules we may need to create ourselves. Particularly this would include MySQL functionality to query Wesnoth's forum database as well as potentially a lua module for UMC scripting, depending on if any of that code would be taken the Wesnoth 1 codebase.
• There are more options than just the GPL or CC suite of licenses, such as MIT, Apache, WTFPL, etc.

Currently the Unit Plate (which shows life / experience / side) of units is created inside of the Unit.tscn.

However, since it's a UI element, I think it should be decoupled from the Unit.tscn and moved to GameUI.tscn.

It would suggest to use a RemoteTransform2D as hook InterfaceHook inside the Unit.tscn, and then create a Unit Plate inside GameUI and t set it to remote_path of that unit. This way it's drawn by the GameUI but should still follow the units.

AMLA -> At Max Level Advancement, means, when advancing, the unit type stays the same, but the unit heals and slightly increases both max health and max experience.

There was talk about an overhaul for how AMLA works.
Suggested was a more advanced AMLA system, closer what is implemented for certain characters in UtBS.

Let's discuss.

• Add a backdrop to make it clear that the game is paused
• Painting in the mapeditor should not be possible while pause is active
• Currently moving units should pause
• and mouse hovering should not select/highlight anything

for Idle animations, they could continue to play, but they could also pause, I don't know which one is better 😄 - let's discuss it below.

Wesnoth 2.0 Alpha

Gameplay

Classic

• upkeep
• rest / village healing
• advancement (#56)
• AMLA (#62)
• combat (#57)
• recruitment (#58)
• factions (#58)
• traits (#84)
• abilities (#20)
• weapon specials ( #59)
• recalls (#60)
• define next scenario for campaigns
• AI

New Mechanics

• Inventory (#66)

Terrain

• add missing terrains
• two-way transitions (#64)
• to-terrain transitions (#65)
• mulit-hex terrains
• castles
• animated terrains

Map Editor

• define ToD schedule
• define number and start positions of sides

Interface

• define main menu visuals
• define game HUD visuals
• scenario settings (selectable factions, gold, income, stuff)
• story screen for campaigns

WDK (Wesnoth Development Kit)

We should set this up and use it for core content as well.

• create units
• create scenarios
• create campaigns
• create events

Networking

• MP Matches
• MP Moderation Tools
• ? Player Profiles (SteamWorks?)
• ? MySQL Module

Content

Units

• Rebels
• Undead
• Loyalists
• Knalgan Alliance
• Drakes
• Northerners
• Dunefolk

Campaigns

• Heir to the Throne

I18N

It may not be fully translated, but it should at least use it to proof concept

• English
• German

As the title says, the game crashes when painting void tiles.
Says "darken" is invalid ID of Registry.terrain.

At the moment it's only Ctrl + F, I would like to have F11 as an option, too.

Right now we have static tilesets for both terrain tiles and transitions.
We should create these tilesets on startup based on the images available in the images/terrain/ folder.

Since GDScript is being used for mods, what language is going to be used for campaigns? Is it going to be in the same format as the test campaign?

It seems

func _update_size():
	width = get_used_rect().size.x
	height = get_used_rect().size.y

in Map.gd does not work properly.
It is supposed to get the dimensions as a rectangle of the map from (0, 0) to what ever extend the tiles are present.

It's quite important to get the map dimensions right, so someone should have a look at it.
(this is mostly because I go to sleep now and want to remember this issue, hah!)

When I run it from the editor loading a game screen takes long sometimes I get the whole game to freeze for a few seconds.
Loading the test scenario has loads without user feedback ~6 seconds after the progress bar is already done.
Also I only get like 36 fps in the test scenario and drops when i move units as low as 26 fps.
The exported version is only like 6 fps better but still drops down to 27.
(I'm on a laptop using Linux)

Anyways Performance on lower end hardware is also an important thing we should keep in mind.

It would be more satisfying if hover would react when mouse pointer hovers over menu item.

Units shall be able to battle.

• Attack enemy units
• choose between attacks
• give xp on kill
• give xp equal to opponent level if opponent does not die
• respect defense and resistances

We need terrains that draw specific transitions only to specific terrains, such as grass-to-water and so on.

I think this bug is something new but I'm not sure.
There is issue with showing FoW turn after attacking:

As you can see vision range is 0 for some reason.

What it should look like:

Steps to reproduce:

1. launch test campaing
2. approach enemy with scout
3. attack enemy
4. end players turn
5. end enemy turn
6. observe FoW issue

Player needs to receive income based on the number of villages they control. Player needs to pay upkeep based on the number of units they own

• Income is: 2 base + 1 per village you control
• Upkeep is: 1 gold per unit level
• Unit with Loyal #84 Trait and Leaders do not cost upkeep

Just cloned this project and loaded it in godot and tried to run it. It crashes on

Method 'draw_arc' is not declared in the current class

Very new to godot, so it could be I have a dependency problem that i'm not sure how to resolve.

Checked the contributing guide but didn't see anything about dependencies or a getting started guide or anything

When you press the attack button when the unit is still moving, the unit stops moving and attacks. However, the unit may not be directly next to the target.

In 1.x we have certain terrains that draw transitions both ways, especially the grass terrains.
We don't have any way to do that in haldric right now.

Currently units of a player are able to:

1. move through other units
2. get stuck on a tile where a unit already stands on, when the ZoC of an enemy unit kicks in

That needs to be fixed.

This project doesn't seem to have a CONTRIBUTING.md file, so it is not clear how to get started.

Please add a contributing file describing how to run the game in development mode, create assets, and other critical tasks. This way, new contributors can quickly get started.

There was talking about supporting inventories / items.
This may be an issue about discussion about how that could look like, and how it may be implemented.

As per the original: When units are recruited they should receive 2 traits from a random choice selection according to their race (e.g. Strong/Intelligent/Resilient etc). Undead should receive only 1 trait always: Undead

When the experience of a unit reaches it's maximum, a unit shall advance.

• advancing to a higher level unit
• possibility to choose between multiple advancements

Discussion and implementation of abilities like healing, curing, regenerating and such for units.

I would approach it similar to the current implementation of attacks.
We have a base Ability Scene (plain Node with Script). For a new Ability, you add a new Node to the Abilities Node in UnitType and attach a script that holds the logic of the wished ability.
New abilities would be script only, extending from a base Ability.gd script to ensure basic functionalities/structure.

If you select other option, like "Campaigns" and then select "Home" back, the whole menu freezes.
I run it in Godot 3.1.1 stable with the following set up:

Ubuntu 18.04.3 LTS 64bits
7.7GB of DDR3 RAM
Processor Intel® Core™ i5-4210U CPU @ 1.70GHz × 4
Graphic Card GeForce 940M/PCIe/SSE2

If multiple units have the same path to an target, the units can attack with the same path. Doing this will result in stacking, and only the top unit will be able to move.

This is for both discussion and implementation of the Lua API, which is needed for scripting scenarios and campaigns in mainline and UMC

(will update updated frequently, as discussion goes on)

Tried the new recruiting code with 3.2. Got the following error

Trying to assign value of type 'Node2D' to a variable of type 'PackedScene'.

Looks like it's coming from: res://source/interface/hud/UnitRecruitmentCard.gd line 12

var unit_type: PackedScene = Registry.units[unit_type_id].instance()

When moving a unit, it seems there is a pause between the unit arriving a tile and start moving to the next tile.

This happens since we introduced FSM to Unit.tscn

Note: Currently the tween is set to TRANS_SINE. This pause also happens when it's set to TRANS_LINEAR.

it appears to be a severe performance drop, so it should definitely be investigated further.

Some people would like to help contributing to the Haldric engine, but they might never have used Godot so far. Would it be possible adding to the CONTRIBUTING.md file (or to another file, in case that one becomes too long) a list of good resources to learn how to use Godot and how to program in GDScript and C#?

Especially for Mobile and touchscreen-only devices.
related to #45

Just a reference list of features we'd like or bugs we come across in Godot that we should either try to implement open issues about.

• Better Easing interface in the Animation player.
• A Close All Scenes context option.
• Vertical GradientTextures.
• Better interface for when nodes are automatically removed when editing an instantiated scene.
• Move Signal and Group tab icons closer to their text so it doesn't look like there are 4 buttons.

Units from side 2 can see units from side 1, but units from side 1 cannot see units from side 2 for some reason.

We discussed the things that we want to have in our prototype. What might also be interesting to know, especially for the new volunteers, is what mistakes we don't want to repeat, which have been made in the Wesnoth 1.x. series.
So please, go ahead and tell us what the mistakes there were and how we could improve on that!

The first load of the scenario takes long: after the progress bar is finished it takes up to 15 seconds until its loaded, if we need that time, a second progress bar for these additional would be appreciated.
When I quit to the main menu and open it again, I see the level nearly directly after the progress bar reaches 100%.

Weapons shall have specials to them, such as poison, charge, etc.

I am thinking a class WeaponSpecial extending Node which provides base functionality, such as a virtual -execute function that shall contain the logic.

To add a Weapon Special, a simple Node would be added to the Attack node, with script extending WeaponSpecial containing the logic.

I'll leave this issue here as collection of features and new mechanics that come up during development.

So far we have

• inventories for units
• UtBS like AMLAs.
• terrain abilities / traps
  - area attacks
  - true ranged attacks
  - stackable units

Hi,

I am not an expert in graphics engine, but since I got terrible performance running haldric on my old laptop (13 fps while it is 40 fps with main wesnoth), I decided to run it through renderdoc on my other computer to see what is happening.

Since renderdoc does not support capture with OpenGL 2, the capture is full of not batched drawcall (The tilemap seems to be drawn with one drawcal per hexagon using the godot GLES3 renderer ! But the GLES2 godot renderer supports batching :/).

But what seems the strangest to me is that the map is drawn entirely three times per "rendering loop": once for the main map, once for the unit zoom and once for the minimap.

I guess you could renderer the minimap to a texture and display it, use that texture as a base to draw the full map to a texture and display it, and use that final texture to draw the unit zoom, thus dividing the amount of draw calls per loop per three (I think in godot you could use godot "viewports" to do this ? -> https://docs.godotengine.org/en/stable/tutorials/viewports/viewports.html).

I hope I did not bother you recalling something you already knew ^^.

Thanks for the amazing work on wesnoth 👍.

Units need to be able to heal HP. Basic methods (i.e. without involving abilities or traits)

• A unit that does not move or is involved in an attack heals 2 HP on its next turn
• A unit which starts its turn in a village or oasis, heals 8 HP

When having multiple scenarios (generally like in a campaign), players shall be able to recall units from previous scenarios.

I once read that one hex tile in Wesnoth is about one mile in length. Given that a day in Wesnoth usually lasts 6 turns, and in each turn the usual infantry moves 5 tiles, this is about 30 hexes / miles per day, (if moving 24/7), which does seem reasonable to me.
What does not though, is the fact that characters in campaigns use to talk to each other without issues even though there are several hexes, thus miles, between them.

Since we're doing this game pretty much from scratch and we also talked about new HD terrain, we could rethink the scales of a hex. Units are treated as single persons all the time already, so we might actually make them single persons, and a single hex tile could me meters, not miles, as an example.

What are your thoughts about this? Your ideas?

See topic

Namely those would be:

• Mouse only

• Mouse + Keyboard shortcuts

• Touch only

• Keyboard only

• Gamepad (like xbox 360 / ps4 controller)

bold stands for important, italics stands for would be nice

Title says it all. The Selector code accesses the locations dict in Map without guarding it with if locations.has(_flatten(cell)) or if is_cell_in_map(cell)

When unit with higher sight spots enemy unit when he is on the tile with another unit it looses selection and stops.

• - It shouldn't be possible to stop on another unit.
• - Unit shouldn't loose selection.