Xalzar's WML Headaches

[skeptical_troll]

This could be quite slow but a way is:
start from the border scanning the whole map with [filter_radius] which avoids your units, obtaining a huge array.

Than store all locations which are not in that array and don't have one of your units. It should give what you want, I think.

[Sapient]

To be safe, you should use the map edges since some maps don't have borders.
Something like this should work I think:

Code: Select all

  [store_map_dimensions]
  [/store_map_dimensions]
  [store_locations]
    [not]
      x=1
      [or]
        y=1
      [/or]
      [or]
        x=$map_size.width
      [/or]
      [or]
        y=$map_size.height
      [/or]
      [not]
        [filter]
        # put encirclement-type unit filter here
        [/filter]
      [/not]
      radius="$($map_size.width * $map_size.height)"
      [filter_radius]
        [not]
          [filter]
          # put encirclement-type unit filter here
          [/filter]
        [/not]
      [/filter_radius]
    [/not]
    [not]
      [filter]
      # put encirclement-type unit filter here
      [/filter]
    [/not]
    variable=encircled
  [/store_locations]

[Xalzar]

To be safe, you should use the map edges since some maps don't have borders.

Luckily, I'm creating a scenario with a very specific map with defined borders. So I have many ways to distinguish the playable area.

Thank you all, I'll have fun experimenting.

[Xalzar]

Hi again! So, I've run into a problem and I don't find the solution anywhere.

I have a weapon special "dummy" with an event incorporated (multiple events really, but it's irrelevant).
I'm still working on it to make it work properly, but it functions if I put the special in a unit's attack.

I also have an AMLA system which adds, removes, changes attacks and other unit parameters.
If I try to add an attack with that weapon special, there's an error which says like this: "closing tag [/attack] not valid for [effect] tag etc.".
Now, the special structure is like this:

Code: Select all

[dummy]
        ...
    [/dummy]
	[/specials]
	[/attack]
	[event]
		1
		...
				[fire_event]
					3
				[/fire_event]
				[fire_event]
					5
				[/fire_event]
		[remove_event]
			id=3,5
		[/remove_event]
	[/event]
	[event]
		2
		...
				[fire_event]
					id=4
				[/fire_event]
				[fire_event]
					id=5
				[/fire_event]
			[/then]
		[remove_event]
			id=4,5
		[/remove_event]
	[/event]
	[event]
		3...
	[/event]
	[event]
		4...
	[/event]
	[event]
		5...
	[/event]
	[+attack]
    [+specials]

If I remove [/attack] and [+attack] the error is solved, but I get the attack with a "dummy" special and no event.
I've never understood how [/x] [+x] tags work in abilities, so I've always just copied from preexisting works (seriously, where it is written how do they work?).
So, apparently events in abilities and specials are not supported inside [effect]? How can I include these "special" specials in AMLAs or other instances of [effect]?

Side question: does the effect of traits apply only on unit creation? Example: strong trait adds melee damage only on attacks already present and not on attacks gained afterwards? 'Cause it seems that way.

[octalot]

I think using [/x][+x] is probably some evil that started as a way to make macros look nice, using the SyntaxWML#Tag_Amendment_Syntax. Avoid using it unless you have to.

It makes sense if used like this:

Code: Select all

[unit_type]
    id=AE_mag_Blood_Warrior
    name= _ "Blood Warrior"
    race=orc
    ...
    [abilities]
        {ABILITY_AE_MAG_FURY}
        [dummy]
            id=AE_mag_bloodlust_5
            name= _ "bloodlust +5"
            description=_"This is some other ability that's unrelated to the Fury ability."
        [/dummy]
    [/abilities]
    ...

where the ABILITY_AE_MAG_FURY needs to expand to both a [dummy] tag inside the [abilities] tag, and also to an [event] tag outside the [abilities] tag. So the macro uses [/abilities][event]...[/event][+abilities] to add its event and then reopen the [abilities] tag so that any other ability, such as Bloodlust, is still in what looks like the same [abilities] tag.

[sergey]

I think using [/x][+x] is probably some evil that started as a way to make macros look nice, using the SyntaxWML#Tag_Amendment_Syntax. Avoid using it unless you have to.

I won't say it is evil for all the cases, consider the next example:

Code: Select all

{GENERIC_UNIT 1 Footpad $x1 $y1}
[+unit]
  gender=female
[/unit]

So, apparently events in abilities and specials are not supported inside [effect]? How can I include these "special" specials in AMLAs or other instances of [effect]?

It is not related to the effect. event is not supported in abilities or specials at all. However, as octalot pointed out, there is a way to make it look like the event is defined inside those tags by using the amendment syntax inside macroses.

How can I include these "special" specials in AMLAs or other instances of [effect]?

The wiki says:

The [event] Tag
This tag is a subtag of the [scenario], [unit_type] and [era]

You can't include events in AMLAs or effects. You could include them in scenario, unit_type or era, depending on the add-on type (SP/MP) and availability of the weapon special (available to any unit or only to a specific unit type).

Side question: does the effect of traits apply only on unit creation? Example: strong trait adds melee damage only on attacks already present and not on attacks gained afterwards? 'Cause it seems that way.

I can confirm that. I am not sure if it will be easy to fix, since it is not obvious what effect must go first in a general case. Considering that effects may change a lot of different things and custom traits are also possible.

[Xalzar]

Thank you both for the pointers! Now I understand [/x] and [+x] tags and why it gives me error, expecially in light of:

The [event] Tag
This tag is a subtag of the [scenario], [unit_type] and [era]

which I mistakenly totally didn't think relevant in this case.

I tried to add [/effect] [+effect] and then [/advancement] [+advancement] and then [/unit_type] [+unit_type] but then [unit] gave me the problem so I decided to stop...
That almost worked though!

Followup question: how can I give the possibility to customize recruitable (or just-recruited) units to players and AI alike? I used AMLAs because AI is able to use those but if there is something better which gives no problems with events inside abilities I'm all ears.

[sergey]

Followup question: how can I give the possibility to customize recruitable (or just-recruited) units to players and AI alike? I used AMLAs because AI is able to use those but if there is something better which gives no problems with events inside abilities I'm all ears.

For a human player you probably want a recruit event that opens a dialog box with available customizations. See message and option https://wiki.wesnoth.org/InterfaceActio ... message.5D

For an AI player you could also use a recruit event, but instead of a dialog box there should be a scripted logic. The logic may be deterministic or it may use RNG to introduce some diversity.

[Xalzar]

Thanks again!

For a human player you probably want a recruit event that opens a dialog box with available customizations. See message and option https://wiki.wesnoth.org/InterfaceActio ... message.5D

Yeah it was my first choice since it's more elegant and easier to implement for human players than other options. But in the end...

For an AI player you could also use a recruit event, but instead of a dialog box there should be a scripted logic. The logic may be deterministic or it may use RNG to introduce some diversity.

...AMLAs were chosen because it seemed easier to implement for AI players (while being decent for humans), but maybe with some clever logics I can mimic sensible choices for our future overlords. I'll definitively study more AIWML and similar pages to see if something there could help me.

[sergey]

maybe with some clever logics I can mimic sensible choices for our future overlords.

By default the AI chooses advancements randomly, at least it is writtent here https://github.com/wesnoth/wesnoth/blob ... pp#L35-L36

I suggest you to stick with a similar approach and don't end up creating a skynet If you know scenario conditions in beforehand (AI units, player units, map, etc) you could tweak your AI with a relatively simple code. Anyway, you probably want your code to be as simple as possible, to make it testable and maintainable.

[octalot]

I tried to add [/effect] [+effect] and then [/advancement] [+advancement] and then [/unit_type] [+unit_type] but then [unit] gave me the problem so I decided to stop...
That almost worked though!

You can use the dummy ability as a filter for the event, and then put the event itself in whichever of [scenario], [unit_type] or [era] seems easiest. For example, the AE_mag_bloodlust_5 ability. The ability itself is a dummy one, but there's a [die] event which uses [filter_second] to only trigger when the killer has the ability (in die events the killer is the second unit).

Code: Select all

    [event]
        name=die
        id=AE_mag_bonecollector_bloodwarrior_event
        first_time_only=no

        [filter]
            [not]
                race=undead
                [or]
                    race=mechanical
                [/or]
                [or]
                    race=AE_mag_magical
                [/or]
            [/not]
        [/filter]
        [filter_second]
            ability=AE_mag_bloodlust_5
        [/filter_second]

        [delay]
            time=100
        [/delay]
        [heal_unit]
            [filter]
                x,y=$x2,$y2
            [/filter]
            amount=5
            animate=yes
        [/heal_unit]
    [/event]

The implementation of the RECRUIT_UNIT_VARIATIONS macro shows how to add a random [effect] to recruited units.

[Xalzar]

Thanks again!

I suggest you to stick with a similar approach and don't end up creating a skynet

Eheh...

You can use the dummy ability as a filter for the event, and then put the event itself in whichever of [scenario], [unit_type] or [era] seems easiest.

Yeah, that's what I was realizing I have to do ultimately. Even if I switch to message-options instead of AMLAs, [effect] is always in the way so the special events need to be incorporated in the unit. Also, there would be essentially no difference from now (in terms of code weight) since the [advancement]s are already written in the unit code, including the event (even if it does not exist in the game because the corresponding special is not selected)...so, better have it written where it does work.

The implementation of the RECRUIT_UNIT_VARIATIONS macro shows how to add a random [effect] to recruited units.

Unfortunately I cannot use variations since the customization is quite complex and I would need dozens of variations (often even more) per unit.
But yeah, a recruit event for AIs with random choice of customization corrected by gold availability, previous recruitment choices and preselected AI behaviour is what I'm thinking now.

[Xalzar]

Quick question: how can I avoid triggering an event if the side is controlled by AI if the 'controller' key of a StandardSideFilter is disabled in MP?
https://wiki.wesnoth.org/StandardSideFilter
The premise of this problem is that the AI side is not fixed necessarily (so I can't filter for the side number), and the AI side doesn't need messages with options (which the human players can see and interact with! ) but specifically tailored different events.

[Ravana]

Whether side is AI or not depends on who looks - 1.14 decided that it is private information whether side is played by AI or something else.

I guess you need something like

Code: Select all

local is_ai = wesnoth.synchronize_choice(
  function()
    return false
  end,
  function()
    return true
  end)

to ask playing side whether it is AI.

[Xalzar]

@Ravana: Thanks! But...is Lua the only solution, really? And it really does not cause OOS?
The problem is that I've never learned Lua and I am unable to try to do it at the moment, due to time constraints. But I'd really like a quick fix to ease testing my code without constantly manually clicking the options for the AI.
In case there is no other way, I'd like to know...is that code workable? How should I insert it in my code? (I need it inside an [event])