Follow-up Comment #7, patch #1032 (project wesnoth):

Okay, to summarize my ideas on this (without horribly marked-up code in my
comment) - I see a different purpose for [endlevel] as opposed to
[loss/defeat/result]:

[endlevel] - this is the direct action that causes an immediate end to the
scenario. The winning team is declared here.

[loss/defeat/result] - this is the direct action that marks a side as
defeated (sides win by default if they haven't been defeated?). Having a side
lose has no further effect on the remainder of the scenario by itself (but the
event calling this might eliminate some units, change them over to an AI side,
etc.).

I don't think that [loss/defeat/result] should be contained in [endlevel],
since usually the events leading to one side to lose happen before the end of
a scenario (loss of leader in MP for one side does not end the scenario for
all).

In comparison, a winning event always concludes a scenario (since the winner
is finalized).

These two direct actions in conjunction would allow a lot of flexibility in
defining victory conditions.

Seeing how this is quite different from your patch/proposal, an alternative
suggestion that is closer to it is having the [result] filter for sides
rather than giving specific side numbers. I imagine that conditions as they
are used in [if] would be better to use than a unit filter:
<code>
[result]
  outcome=loss
  continue=no
  [have_unit]
    side=$side
    canrecruit=1
  [/have_unit]
  [or]
    [variable]
      name=caravans[$side].remaining
      less_than=1
    [/variable]
  [/or]
[/result]
</code>
I hope this second proposal is more useful for you, and wish you good
progress with your work in whatever way you choose! :)

    _______________________________________________________

Reply to this item at:

  <http://gna.org/patch/?1032>

_______________________________________________
  Nachricht geschickt von/durch Gna!
  http://gna.org/


_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs

Reply via email to