bugBattle for Wesnoth - Bugs: bug #21882, Scenario with only leaderless AI...

 
 
Show feedback again

bug #21882: Scenario with only leaderless AI side ends with defeat as soon as it starts

Submitted by:  Matthias Schoeck <mattsc>
Submitted on:  Tue 01 Apr 2014 02:25:02 PM UTC  
 
Category: BugSeverity: 4 - Important
Priority: 7 - HighItem Group:  None of the others
Status: Ready For TestPrivacy: Public
Assigned to: Chris Beck <involution>Open/Closed: Open
Release: 1.11.12Operating System: all

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 02 Jun 2014 10:52:07 AM UTC, comment #13:

@involution

> I have corrected the part about modify_side not affecting the defeat condition, that was intended to be added.

But why? Some people don't know lua, and would like to be able to control defeat_condition via modify_side

>After this is backported, I believe that there will be no way to end the game for just one defeated side. Of course you can mimic it in WML if desired.

You mean if my "user-defined" victory conditions are met then I can immediatelly end all turns of that side, but the side will still be considered as alive?

Hm ... now I see my question was pointless:
my original concern was whether BfW allowed to determine any user-defined victory conditions. Now I see I missed next procedure was possible:
- The addon author sets [side] defeat_condition=never
- he checks his user-defined victory conditions in events
- Once his user-defined victory conditions are met, he removes all units of that side, he sets defeat_condition=no_leader_left and he uses [end_turn].

So it looks BfW allows any user-defined victory conditions.

SlowThinker <slowthinker>
Fri 30 May 2014 03:37:09 AM UTC, comment #12:

SlowThinker: I have corrected the part about modify_side not affecting the defeat condition, that was intended to be added.

Also, I wrote this on the wiki today: http://wiki.wesnoth.org/ScenarioWML#Scenario_End_Conditions

I agree it would be a good idea to put links between the related documentations... I didnt realize there was redundant docs in the LuaWML section, thanks for pointing this out.

Regarding this:

" But can one end the game just for one defeated side? "

Currently (in 1.11.15) it was possible, when using the Victory When Enemies Defeated field, to have some clients terminate in defeat while other clients continue, and I continued to preserve this behavior in the code to adhere to the docs. But after testing we discovered that actually that behavior is totally broken in mp, and there is no netcode to support it and it creates bugs. So in master we have patched it. Sides may be defeated at any point, but the game will continue as long as there is any (local or remote) human controlled side which is not defeated, and then they will all end in victory or defeat together.

After this is backported, I believe that there will be no way to end the game for just one defeated side. Of course you can mimic it in WML if desired. But I think it will seriously break the networking assumptions if some sides enter linger mode when others do not.

Chris Beck <involution>
Project MemberIn charge of this item.
Thu 29 May 2014 09:23:14 PM UTC, comment #11:

defeat_condition solved my problem, because I can temporarily assign defeat_condition to "never".
But I am curious whether one could firmly assign defeat_condition to "never" within [side], and then apply arbitrary victory conditions?
Sure, by WML/lua tools one can [endlevel] when all teams except one are defeated. But can one end the game just for one defeated side?

a point concerning the wiki:
parts of the wiki that mention defeat_condition (in present sideWML and LuaWML:Sides#wesnoth.sides) should point one to another

SlowThinker <slowthinker>
Thu 29 May 2014 06:56:38 PM UTC, comment #10:

1.11.15:
for people that don't know lua and won't use wesnoth.sides.defeat_condition, it should be possible to set 'defeat_condition' by [modify_side]

SlowThinker <slowthinker>
Sun 18 May 2014 09:56:30 PM UTC, comment #9:

SlowThinker:

This function is more or less the entire victory conditions, actually. It's true that you can run out of time, but I believe this is implemented using an event trigger. It's true that WML can end the level, but this works by essentially the same mechanism that check_victory ends the level, they ultimately raise an end level exception that breaks out of the game loop.

Besides those two possibilities afaik check_victory is the only other way, and rather, the main way that the level ends.

check_victory is pretty simple, it just looks at the board and says "is anything happening? is there any conflict possible?" if yes, then ofc it doesnt end. If no... then it checks if "victory_when_enemies_defeated" = no, i.e. we are in a cutscene of some kind.

Setting aside the concerns of major UMC, from the perspective of KISS I think it's pretty reasonable to have conditions like this that we check regularly to end the level. A beginner WML programmer will expect that if after some event he killed the enemy leader, victory should be declared. If it doesn't happen, it could reasonably be considered a bug.

Our approach (more or less the same as always I think) is to check the conditions as frequently as necessary, but allow extra flags and options so that custom scenarios can get the behavior they want. I expect that our final solution will be along these lines.

I don't like the idea (mentioned elsewhere) to try to remember whether leaders were killed by WML or attacks... I have no idea where we would even put that info in the engine, it seems potentially burdensome / impractical. I think it's usually better if WML has the upperhand over the engine and the engine is not "aware" of what the WML is trying to do at any time.

We are continuing to discuss this and we'll push some kind of fix for this soon, that most likely will allow you to kill all the units for as long as you like.

Chris Beck <involution>
Project MemberIn charge of this item.
Sun 18 May 2014 03:41:29 PM UTC, comment #8:

First some thoughts:
A) there is a function check_victory() that checks the default victory conditions. The default victory conditions are "at least one unit with canrecruit=yes must be present and the turn limit must not be overpassed"(?)
B) there is a mechanism that prevents all units are killed is required, since it could cause a bug

I don't understand why A) and B) are mixed together: IMO these points should have nothing common and should be independent. Mixing independent stuff is a way how to get bugs.
A) should not be called at the end of every single synced_context
B) should not end the scenario directly, but raise some kind of an exception first (a special event, or show an error mesage ...)

B) is a problem, because it is natural: UMC creators want to kill all units and to change the map environment.


Now my answers:

>gfgtdf wrote:
>If you want controll more control over win/loose cou should use fight_on_without_leader=yes.

iceiceice says even fight_on_without_leader=yes doesn't prevent the scenario ends when all units are killed by WML/lua.

>gfgtdf wrote:
>Previously this only happend after actions of the ai. I changed that so that it now also happens after actions by humans too, especialy becasue i think that human moves should have the same effect as ai moves.

I agree that human and AI should have the same effect. But you should rather remove the check after AI moves: the presence of leaders need to be checked in 'die' events only.

>iceiceice wrote:
>Dugi asked if we could change check_victory so that we also search the recall list for leaders.
> ...
>Killing all the units is a fairly common thing to do in WML it seems, my guess is that alot of UMC is affected so we might do something esp. if there is a consensus about what the change should be. We could perhaps make a lua-accessible flag to block the check victory function for example, I guess.


Yes, in order to make point A) more flexible, it would be nice if UMC creators could suppress check_victory() by [modify_side] or lua.
But I don't see how it could be achieved since there is point B): an engine condition that all units may be never killed, unless the scenario ends.
(Personally I think such an engine condition is unnatural and bad, killing all units should be allowed and the possible bugs should be solved another way.)

SlowThinker <slowthinker>
Sun 18 May 2014 03:22:25 PM UTC, comment #7:

First and in order to keep things together, I will forward a PM from iceiceice:


"
So I spoke with gfgtdf on the channel about this.

Based on our chat on the mp server I think you might think that fight_on_without_leader is supposed to "fix" this problem. It's not really though. fight_on... is just supposed to make units with canrecruit=no count also as leaders for purposes of the check_victory conditions. fight_on is not supposed to stop the scenario from ending if all the units have been killed.

The real issue that you are describing is that check_victory is being called more often. gfgtdf tells me that now, this function is called at the end of every single synced_context.

https://github.com/wesnoth/wesnoth/blob ... xt.cpp#L67

He says that if we don't do this, we can get bugs, such as the game continuing from the player's point of view if all units are killed by innocuous WML in a move_to event.

There was some discussion of the changes in the "scenario and campaign development" forum in SkyOne's and Dugi's thread. Dugi asked if we could change check_victory so that we also search the recall list for leaders. I would consider doing this if other umc developers felt it would make things less clumsy. Killing all the units is a fairly common thing to do in WML it seems, my guess is that alot of UMC is affected so we might do something esp. if there is a consensus about what the change should be. We could perhaps make a lua-accessible flag to block the check victory function for example, I guess.

~iceiceice~
"

SlowThinker <slowthinker>
Wed 14 May 2014 08:07:49 PM UTC, comment #6:

> A) I consider this system to be natural: The presence of leaders is checked if and only if a unit is killed in a combat.
> Reason: any other kill of a leader is fully controled by a WML/lua coder, and he can decide himself whether he wants to end the scenario or not.


There are attack end/last breath/dies ... event so the wml designer also have teh attacks under control.
If you want controll more control over win/loose cou should use fight_on_without_leader=yes.

> C) In BfW 1.11.13, the presence of leaders is checked more often than before, for example after [kill]. It is a completely new mechanism and it goes against the principle explained in A)


No it checks the presence of leaders after every player action like menu items clicks, moves, recruits, ..., not after special wml actions, especialy if you [kill] a leader and then bring him back on the same event you won't get defeated, if you lost in that situation it is most likeley a bug.
Previously this only happend after actions of the ai. I changed that so that it now also happens after actions by humans too, especialy becasue i think that human moves should have the same effect as ai moves.
Also in order to fix another bug related to side cayyover

Daniel <gfgtdf>
Project Member
Wed 14 May 2014 07:21:18 PM UTC, comment #5:

After my chat with involution I will clarify some things.
How BfW engine checks/should check leader kills and possibly end the scenario:

A) I consider this system to be natural: The presence of leaders is checked if and only if a unit is killed in a combat.
Reason: any other kill of a leader is fully controled by a WML/lua coder, and he can decide himself whether he wants to end the scenario or not.

B) (according to an explanation by involution,) BfW checks the presence of leaders at end of a turn. It seems not to be an ideal mechanism, but it is like BFW behaves long time.

C) In BfW 1.11.13, the presence of leaders is checked more often than before, for example after [kill]. It is a completely new mechanism and it goes against the principle explained in A)

SlowThinker <slowthinker>
Tue 06 May 2014 11:27:59 AM UTC, comment #4:

Clarification of a sentence:
I don't understand why in BfW 1.11.13 a scenario may be automatically ended after a leader kill invoked by a WML code: the WML coder has the kill under his control and should decide himself whether he wants to [endlevel] or not.

SlowThinker <slowthinker>
Tue 06 May 2014 12:05:45 AM UTC, comment #3:

Apparently the presence of leaders is checked much more often in BfW 1.11.13 than in BfW 1.10 and 1.11.11 (no idea about 1.11.12). In past, for example one could clear the map by
[store_unit] kill=yes
do some stuff and then restore the map and units. Now it ends the scenario.

I don't understand why a scenario may end by a leader kill invoked by a WML code (the WML coder has the kill under his control and may decide whether he wants to [endlevel] or not).

But if it is really needed then at least fight_on_without_leader= should be dynamic, i.e. it should work also within [modify_side]

SlowThinker <slowthinker>
Wed 09 Apr 2014 01:40:29 AM UTC, comment #2:

Now merged into 1.12 and master. I tested the patch with animals scenario, it seemed to work. But let me know if it doesn't work in some other case.

Chris Beck <involution>
Project MemberIn charge of this item.
Tue 08 Apr 2014 11:55:47 PM UTC, comment #1:

Proposed patch is here:

https://github.com/wesnoth/wesnoth/pull/142

I will be testing this soon, please check that it meets your needs and I will merge it.

Chris Beck <involution>
Project MemberIn charge of this item.
Tue 01 Apr 2014 02:25:02 PM UTC, original submission:

Before Wesnoth 1.11.12 it was possible to have scenarios (or turns, cutscenes, ...) in which two AI sides battled each other (as the only sides present) as long as victory_when_enemies_defeated=no was set. Now such a situation will bring up the "you have been defeated" dialog and end the scenario.

In order to work, a scenario currently needs at least two AI sides, each of which needs to have a leader. The sides also need to be enemies of each other.
Note: this only happens if there is no human controlled side in the scenario.

The easiest way to reproduce this is to start the animals Micro AI test scenario from the commandline with
wesnoth -t animals
and select "watch the animals" at the opening question. The scenario will immediately end. (Yes, this is a complicated scenario with lots of extra stuff in it, but it's easy because it exists already and can be started directly from the commandline). Otherwise, you can simply set up any scenario with only two sides with controller=ai and no_leader=yes. It does not need anything else.

This has been discussed on IRC and the cause is known. The best solution is still being discussed as the root cause is an internal logic error that has been around for a long time, but was only brought to light due to a recent internal change.

Matthias Schoeck <mattsc>
Project Member

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by slowthinker (Posted a comment)
  • -unavailable- added by involution (Posted a comment)
  • -unavailable- added by mattsc (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 09 Apr 2014 01:40:29 AM UTCinvolutionStatusIn Progress=>Ready For Test
    Tue 08 Apr 2014 11:55:47 PM UTCinvolutionStatusNone=>In Progress
      Assigned toNone=>involution
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup