[resolved] event firing tied to count function

[tribes55]

Hi guys,

I've been trying to write an event which will fire when side once reaches a total of eight units. I figured I could use the count tag for this, and It was recommended that I use the recently added "unit placed" event name. However, I can't get it to work right.

These units are obtained via the [modify_unit] tag, where I switch their side.
This is what I have so far:

Code: Select all

[event]
name=unit placed		
	[filter_condition]
			[have_unit]
				side=1
				count=8
			[/have_unit]
	[/filter_condition]
	[message]
		speaker=Gandfal
		message= _ "Alright, I think it's about time we move on. I don't think we'll get anyone else."
	[/message]
[/event]

What I want to happen is for this event to fire when side one reaches eight units. This doesn't happen. Anyone know another way, or what I'm doing wrong?

Thanks!

EDIT: I was told that switching a unit's side doesn't fire this event. I have an idea, although it's very hacky I guess. I'll just kill the units and respawn them in. The creation of the unit should fire the event, right?

[tribes55]

Hi guys, I doubt anyone will ever need anything as specific as what I needed, but this is how we resolved it ( I had help from IRC):

Changed the event name to a custom event

Code: Select all

[event]
name=count_units
first_time_only=no
	[if]
		[have_unit]
			count=8
			side=1
		[/have_unit]	
		[then]
			[message]
				speaker=Gandfal
				message= _ "Alright, I think it's about time we move on. That's all we're going to get."
			[/message]
		[/then]
	[/if]
[/event]

And we included

Code: Select all

[fire_event]
name=count_units
[/fire_event]

In every event which modified the side of a unit.


Alternatively, a path I did not take was to kill the unit and respawn it, but that's much more rough around the edges.

Thanks for the help.

[ResExsention]

Have you also tried to stop the player from recruiting? I've noticed that Gandfal just said that they would move on, but nothing is actually forcing the player to do just that. From what I know (if you haven't just spawned a whole bunch of orcs near Gandfal's keep and chased him out of it), the player could just keep recruiting over and over again until he (or she) runs out of gold, which would kind of suck, if you intended to limit Gandfal's recruits to 8. Here's how to stop the player from recruiting if she (or he) has already recruited 8 times:

Code: Select all

[event]
name=count_units
first_time_only=no
	[if]
		[have_unit]
			count=8
			side=1
		[/have_unit]	
		[then]
			[message]
				speaker=Gandfal
				message= _ "Alright, I think it's about time we move on. That's all we're going to get."
			[/message]
			[disallow_recruit]
				type= # Whatever Gandfal can recruit; a comma separated list
				side= # Whatever Gandfal's side is
			[/disallow_recruit]
		[/then]
	[/if]
[/event]

This should suffice.

[Ravana]

The event would look cleaner with [filter_condition] instead of [if][then].

[Sapient]

EDIT: I was told that switching a unit's side doesn't fire this event.

If that's true, it sounds like a bug. The documentation on the wiki states that it is fired for every unstore.

[Ravana]

It depends on how side is changed, new ways no longer require unstore.

[Sapient]

So, the implementation details changed. For example, maybe modify_unit no longer relies on unstore_unit. OK? I still see that as a bug. The "unit placed" event no longer functions as intended. The workaround proposed here is far from ideal.

[Samonella]

So, the implementation details changed. For example, maybe modify_unit no longer relies on unstore_unit. OK? I still see that as a bug. The "unit placed" event no longer functions as intended. The workaround proposed here is far from ideal.

I'd disagree. Modify_unit isn't placing a unit on the map, it's only, well, modifying one. It isn't consistent for "unit placed" to apply to [modify_unit] just because it's used in similar situations as [unstore_unit]; really its a lot closer to [heal_unit] and many other tags that "unit placed" obviously shouldn't apply to.

In a situation where an event should fire whenever any unit changes in a certain way, then it's up to the author to make a custom event, because only the author knows exactly which changes are of interest.

In this particular situation, where the event should fire both for certain wml and for new unit creation, I'd make the event like this:

Code: Select all

[event]
    name=unit placed
    id=count_units
[/event]

And a macro like this:

Code: Select all

#define MODIFY_WITH_COUNT SUF
[modify_unit]
    [filter]
        {SUF}
    [/filter]
    <whatever modification you're making>
[/modify_unit]
[fire_event]
    id=count_units
    [primary_unit]
        {SUF}
    [/primary_unit]
[/fire_event]
#enddef

[Sapient]

I'd disagree. Modify_unit isn't placing a unit on the map, it's only, well, modifying one.

The documentation says that unstore should trigger it. Unstore is (or was) a catch-all for any unit modifications, not just placing a unit with a new id. Otherwise there can be many edge cases where a unit become placed unexpectedly through transformation.

In a situation where an event should fire whenever any unit changes in a certain way, then it's up to the author to make a custom event, because only the author knows exactly which changes are of interest.

Maybe in the past that would have been a viable strategy, but currently Wesnoth allows modifications to be used in a modular way. A modification that uses gold to grant privileges, for example, could transform a unit from level 1 to level 2. That's just one example.

[Ravana]

You ask for separate event then - unit modified.

[Samonella]

In a situation where an event should fire whenever any unit changes in a certain way, then it's up to the author to make a custom event, because only the author knows exactly which changes are of interest.

Maybe in the past that would have been a viable strategy, but currently Wesnoth allows modifications to be used in a modular way. A modification that uses gold to grant privileges, for example, could transform a unit from level 1 to level 2. That's just one example.

That's a good point. Still, I don't think that mixing and matching add-ons should be too high a priority, sometimes there will be conflicts no matter what.

You ask for separate event then - unit modified.

Wow, now that would be a catch-all event. It would have to fire for every "enter hex," every "attacker hits," every rest heal... you'd need some very good filters, but that could definitely be useful. Maybe with a special wml_only= tag, so you can ignore normal gameplay.
EDIT: Ooh, and what if $second_unit held the unit's previous state?