Gloria Victis code issues

[Ceres]

Another thing in you code snippet is that 'side' is not a valid key for [message] AFAIK.

[message] takes a SUF and side is therefore a valid key.

[Neuromancer]

Im trying to copy the units from side 1 to recall list of side 4, but it wont work.
Inspect command indicates there are copies created and their side is switched too, only the units are not in team 4 recall list. I use this code:

Code: Select all

	[store_unit]
		[filter]
			side=1
		[/filter]
		variable=copies
		kill=no
	[/store_unit]
     {FOREACH copies i}
	   {VARIABLE copies[$i].side 4}
	   [unstore_unit]
		  variable=copies[$i]
		  x,y=recall,recall
	   [/unstore_unit]
	   {NEXT i}

[Sapient]

Well the code looks right. Are you sure they're not in the recalls list?
If so, you might try putting this before [unstore_unit] :

{VARIABLE copies[$i].x recall}
{VARIABLE copies[$i].y recall}

[Neuromancer]

Well, Im sure as far as inspect is sure. And am I assuming right AI-controlled sides with empty recruit field will try to recall?
I tried your piece of code, but it didnt work.
In attachment are zipped campaign files: to reproduce, start game on normal, pick random recruits and on world map go north into dried trees (they will be marked by icon). In that scenario, necrophage is leader of the side which wont recall.

[mattsc]

I haven't downloaded and checked out your campaign file, but could you try something? Put "persistent=yes" into the side definition of Side 4 for this scenario (I assume that this is an AI controlled side?) and see if it works then. I think (maybe I misremember and am saying something stupid; again ) I've encountered it before that I cannot put units on a side's recall list that isn't persistent (i.e. either player controlled or with the parameter set specifically), but I haven't done enough research yet to figure out whether that is always like that or just for the cases I have tried (and whether it's supposed to work that way or not).

EDIT: Well, thinking about it, that does make some sense. Why would a non-persistent side need a recall list - under normal circumstances at least? But I still don't know whether it is implemented that way. It's probably documented somewhere, but I don't have time to look for it right now.

[Neuromancer]

It... actually works! Thanks a lot!

[Neuromancer]

This should be the last set of questions. The scenarios are done now - except for a few parts which needs tweaking:

1. I'm trying to insert animated fountain, but engine tells me [terrain_graphics] is not supported:

Code: Select all

    [terrain_graphics]
        x={X}
        y={Y}
        [tile]
            x=0
            y=0
            [image]
                layer=0
                name="../scenery/fountain-animated-1.png:140,../scenery/fountain-animated-2.png:140,../scenery/fountain-animated-3.png:140,../scenery/fountain-animated-4.png:140"
            [/image]
        [/tile]
    [/terrain_graphics]

2. This code stores units of side 1 and changes some of their variables, so they can be recruited by another side. How to change their IDs?

Code: Select all

	[store_unit]
		[filter]
			side=1
			[not]
				id=Hazael
			[/not]
		[/filter]
		variable=copies
		kill=no
	[/store_unit]
     {FOREACH copies i}
	   {VARIABLE copies[$i].side 4}
	   {VARIABLE copies[$i].canrecruit no} 
	   {VARIABLE copies[$i].x recall}
	   {VARIABLE copies[$i].y recall}
	   [unstore_unit]
		  variable=copies[$i]
		  x,y=recall,recall
	   [/unstore_unit]
	   {NEXT i}

As always, sincere thank you for all your answers.

[artisticdude]

For the first problem, you are including the code at scenario toplevel, correct?

For the second, the unit's id is automatically stored when you use [store_unit] (which you can see using the debug command :inspect ). To change the id of the unit, you need to modify the variable id within the container copies[$i], like so:

Code: Select all

{VARIABLE copies[$i].id This_is_the_new_id}

[Morath]

This event fires, but only when Side 1 captures a village, that is owner_side contains the side which does the capture, not the previous owner side as it says at EventWML. Furthermore, the owner_side variable displayed both by [inspect] and in the message is always 0. So unless I misunderstand something here, this looks like a bug to me.

I can confirm the occurence of the $owner_side variable being 0 in a multiplayer campaign I am developing for version 1.10.0 when according to the documentation http://wiki.wesnoth.org/EventWML it shouldn't be. At least I feel more confident that I have not made a mistake somewhere. I have attached the (messy) scenario I am working on that has some debugging messages if it helps. Time for me to write a work-around for this bug.

[Neuromancer]

Time to finish this campaign. You were great help before, could you help me again?

In one scenario, player is advancing into forest where hostile woses have settled. When players unit stumbles onto one, I want him/her to say something. I chose to use sighted event, because (if I understood correctly) from 1.11. it should work with units with hides ability. Im using version 1.11.6. Player is side 1, woses are 3. This code does nothing:

Code: Select all

[event]
	name=sighted
	[filter]
		side=3
	[/filter]
    [filter_second]
		side=1
    [/filter_second]
	   [message]
		   speaker=second_unit
		   message= _ "<i>Gasp!</i>"
	   [/message]
[/event]

Another situation is when heroes are escaping into cave, one by one. Its done by moveto event, which stores, then kills every unit which steps on the specified tile. When there are only 2 units left, one on the field and one entering the cave, I want the one entering the cave say something like "Hey $last_unit, quickly to the caves!" How to store that one unit into the $last_unit variable?

[pyrophorus]

Hi !
I would use a 'moveto' event instead with a filter_adjacent tag describing the hiding wose. (Or even a new 'enter' tag, but I never used them).

HTH

[JaMiT]

I chose to use sighted event, because (if I understood correctly) from 1.11. it should work with units with hides ability.

You understand perfectly. Feel free to put emphasis on "should" -- apparently some idiot forgot to actually implement that aspect when I was fixing up the sighted events. It'll be in 1.11.7 (and in trunk by the end of the weekend, possibly within an hour or so, in case you want it faster ).

Well, ambush will be fixed. I might have to update the documentation to say that nightstalking units do not get a sighted event at the end of a night's last turn.

How to store that one unit into the $last_unit variable?

Perhaps:

Code: Select all

    {STORE_UNIT_VAR (
        # Assuming side 1 is the side with two units left:
        side=1
        # Not the unit who triggered this moveto event.
        [not]
            id=$unit.id
        [/not]
        ) name last_unit_name}

I changed the variable name because "last_unit" suggests it holds an entire unit, but that would not go with your use of "$last_unit", which suggests the variable holds just the unit's name.