[recall] when the unit might be dead

[Helmet]

Using the recall tag is simple enough, but there are a few recall-related situations that are not so simple.

I want to remove a unit (id=Boolzak) from the map. I can't use kill, as it removes him from recall list, and I want him on the recall list. Is this how you would do it? Is there a better way?

Code: Select all

		[store_unit] # 					use [store_unit] to remove Boolzak from the map
			[filter]
				id=Boolzak
			[/filter]    
			variable=Boolzak_store
			kill=yes
		[/store_unit]

		[put_to_recall_list] #				put Boolzak on the recall list
			id=Boolzak
			heal=yes
		[/put_to_recall_list]

In a later scenario, I want a loyal unit (id=Grizz) to appear on the map via recall. He may or may not be on the recall list, however, because he might have been killed in the previous scenario. If he's dead, I would like to create another loyal unit and put him on the recall list, and recall him in Grizz's place.

Or should I simply create the new unit right on the map? Is that what you would do?

I need to ensure that I don't end up with Grizz and a new unit at the same time. Should I try to recall Grizz, and then check with have_unit to see if he's on the map? And if he isn't, create a new unit in that location?

[Lord-Knightmare]

I want to remove a unit (id=Boolzak) from the map. I can't use kill, as it removes him from recall list, and I want him on the recall list. Is this how you would do it? Is there a better way?

Just this is fine:

Code: Select all

                [put_to_recall_list] #put Boolzak on the recall list
			id=Boolzak
			heal=yes
		[/put_to_recall_list]

In a later scenario, I want a loyal unit (id=Grizz) to appear on the map via recall. He may or may not be on the recall list, however, because he might have been killed in the previous scenario. If he's dead, I would like to create another loyal unit and put him on the recall list, and recall him in Grizz's place.

Code: Select all

[event]
    id=Helmet_Recall_Unit_Grizz
    name="new turn"
    
    [if]
        [have_unit]
            id="Grizz"
            search_recall_list=yes
        [/have_unit]
        [then]
            [recall]
                id="Grizz"
                x,y=23, 5
            [/recall]
        [/then]
        [else]
             {LOYAL_UNIT 1 "Cave Bear" recall recall}
             [+unit]
                 id="Grizz_replacement"
                 # add traits and new abilities with a modifications tag
             [/unit]
             [recall]
                  id="Grizz_replacement"
             [/recall]
        [/else]
    [/if]
[/event]

Or should I simply create the new unit right on the map? Is that what you would do?

Better to just use {LOYAL_UNIT 1 "Cave Bear" 23 5}

I need to ensure that I don't end up with Grizz and a new unit at the same time. Should I try to recall Grizz, and then check with have_unit to see if he's on the map? And if he isn't, create a new unit in that location?

the search_recall_list=yes does the checking for you. If he is not in the recall list, you get the replacement loyal unit instead.

[Helmet]

Awesome! I suspected there was a better way. Thank you, Lord-Knightmare.

[Celtic_Minstrel]

My only amendment to that code is that id="Grizz_replacement" should probably just be id="Grizz". Otherwise, it'll be really inconvenient to reference that unit from later events.

[Helmet]

My only amendment to that code is that id="Grizz_replacement" should probably just be id="Grizz". Otherwise, it'll be really inconvenient to reference that unit from later events.

What I did was make the replacement unit of Grizz his sister, Grizzil. If Grizz is dead, she steps up to take his place in the next scenario. It works well, story-wise.

[Celtic_Minstrel]

I see. Then it might make sense to assign the same role to Grizz and his sister, at least if you want them to potentially say the same lines.

[Helmet]

I see. Then it might make sense to assign the same role to Grizz and his sister, at least if you want them to potentially say the same lines.

I need to learn how to use role. I bet it would make dialogue much easier.

This is what I did when I wasn't sure who would be talking, Grizz or Grizzil...

Code: Select all

[message]
	x,y=19,2 #		<< Grizz or Grizzil
	message="Prince Ziffid, I heard that our military forks were originally designed by humans..."
[/message]

I took a wild guess that I could filter a message based on x,y, and it worked.

[WhiteWolf]

I need to learn how to use role. I bet it would make dialogue much easier.

You just use [role] to assign one to a unit, and then you can use role= in [message]. Roles are probably best used to make a non-major character say something, and make it a bit randomized about who this non-major character will be.

I took a wild guess that I could filter a message based on x,y, and it worked.

That's correct, [message] accepts Standard Unit Filter, so all of its keys are recognized. The most commonly used speaker key is actually just an alias that also accepts special values like 'narrator'. But for example speaker=unit is equivalent to id=$unit.id in a [message].

[Celtic_Minstrel]

Yeah, you can filter by location, but that only works when you know exactly where they are.

By the way, your example also has another problem - it's impossible to correctly translate it to some languages (for example Japanese). If you want to fix that, you need to use `male_message` and `female_message`. (If you don't care about translations, then you can leave it how it is.)

[Helmet]

By the way, your example also has another problem - it's impossible to correctly translate it to some languages (for example Japanese). If you want to fix that, you need to use `male_message` and `female_message`. (If you don't care about translations, then you can leave it how it is.)

Thanks for the reminder.

I temporarily halted making anything translatable after a bug appeared in my code. I had made a translatable team_name, and that caused an enemy faction to appear as an ally. It didn't occur to me for a long time to suspect that the translation code was the culprit, so that problem took me a while to resolve.

In the event that more translation-related bug exists, I temporarily halted translating anything until all my code ran properly. Thankfully, I'm finally at that point.

Say, that might be a nice addition to WML: eliminating the bug where a translatable team_name mysteriously breaks your game.

[WhiteWolf]

Say, that might be a nice addition to WML: eliminating the bug where a translatable team_name mysteriously breaks your game.

This is not a bug. Making any id-type value translatable will cause all kinds of issues, since that lets translations overwrite stuff that is handled by the game. The things that should be translatable are the aesthetic stuff, text that is shown to the player but is meaningless to the engine.
team_name is like an id for the "alliance", so that one is meaningful to the engine, therefore it mustn't be translatable. The key you mean is user_team_name, this is the shown text. This is the one that should be translatable.

[Helmet]

I didn't know it was an id. Now it makes sense.

I wish it had been called something different, like team_id, though. Or if a person did mistakenly try to translate it, they would get an error message telling them not translate it.

Thanks for explaining.