Add Win conditions as an Objective

[GunChleoc]

In non-scenario games, add the win conditions as an objective, so they can be easily reviewed later.

Do we want to completely shift them away from the messages? In that case, the Tutorial text will need revising after the change.

[Hans Joachim Desserud (hjd)]

I think this would make sense too, it's a more natural place for the goals of the game than the first message received.

Though how do we intend to deal with the update/status messages related to win conditions? For instance the "you own the majority of the map, hold it for X minutes in order to win". We could of course update the objectives list, but this won't notify the player. In the campaigns, this feedback is provided through story dialogs, though that won't really work in multiplayer since it relies on pausing the game. So unless someone has a better idea, we probably need to keep using the "news" messages for these status messages.

>the Tutorial text will need revising after the change.
Could you elaborate abit or mention an example which would need changing.

[Shevonar (shevonar)]

I can see two more possibilities here that however require some more work.

The first one is to somehow notify the user that an objective was updated. An acoustic signal and/or a blinking objectives icon come to mind.

The second one is a change in the handling of story dialogs that I am currently working on in my new GUI branch (not yet on launchpad). It will handle story messages entirely different and no longer require the came to get paused. This will enable story messages also in replays or multiplayer games. Though it will take a long time until my branch is ready to be published.

[GunChleoc (gunchleoc)]

If we get around to this before the new branch is merged, I'd say have both objectives and game messages when an objective gets updated, but at the beginning only the objective.

We can always revisit later after we have the new capabilities.

The tutorial text is not affected, I misremembered - there is a message about the headquarters, not about any starting objectives.

[GunChleoc (gunchleoc)]

I've run into my first problem this function here. I want to do this:

https://wl.widelands.org/docs/wl/autogen_wl_game/#wl.game.Player.add_objective

but the win condition script is called for each player, so I should do this only for the current player.

How do I find out who the interactive player is? In singleplayer mode, this is simply wl.Game().players[1], but in multiplayer mode I have a problem.

[SirVer (sirver)]

Why not do it for all of them?

> Am 27.05.2014 um 20:21 schrieb GunChleoc <email address hidden>:
>
> I've run into my first problem this function here. I want to do this:
>
> https://wl.widelands.org/docs/wl/autogen_wl_game/#wl.game.Player.add_objective
>
> but the win condition script is called for each player, so I should do
> this only for the current player.
>
> How do I find out who the interactive player is? In singleplayer mode,
> this is simply wl.Game().players[1], but in multiplayer mode I have a
> problem.
>
> --
> You received this bug notification because you are subscribed to
> widelands.
> https://bugs.launchpad.net/bugs/1322473
>
> Title:
> Add Win conditions as an Objective
>
> Status in Widelands:
> In Progress
>
> Bug description:
> In non-scenario games, add the win conditions as an objective, so they
> can be easily reviewed later.
>
> Do we want to completely shift them away from the messages? In that
> case, the Tutorial text will need revising after the change.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands/+bug/1322473/+subscriptions

[GunChleoc (gunchleoc)]

I think I analysed this wrong: If I add an objective to more than one player, all the players see it. I suspect that objectives are global, although you need a player to create one. For initial objectives, this is fine - I can just assign it to player 1 and everybody sees it. But if we want to give players individual updates later in the game, it can't be done.

So, shifting the initial win condition from messages to objectives is done, updates are still sent though messages.

[GunChleoc (gunchleoc)]

Done some more digging - although add_objective is called at the Player object, it is actually a property of the map and not the player. I don't want to touch this with a bargepole right now, so I'm proposing my branch for merging.

In case somebody will tackle this later, the Lua scripts to take care of are:

- win condition scripts
- MP and SP scenarios
- campaigns

[SirVer (sirver)]

I think a possible approach here could be to add the player(s) as a property to the objective - if not set it defaults to the first player. This way the objectives can stay properties of the map (as they are saved and loaded there) but each player can have her own and objectives can even be shared (i.e. it is okay if only one of the player fullfills it).

[GunChleoc (gunchleoc)]

Sounds like a plan :)

[GunChleoc (gunchleoc)]

I've opened a new branch to work on the multiplayer-capable version.

Changing the Objective object was easy, now for the hard part:

Calling

 plrs[player_number]:add_objective(player_number, name, title, body)

is an invitation for bugs because of the repetition of player_number, so I need to keep the function call as it is:

 plrs[player_number]:add_objective(name, title, body)

and find out within

 int L_Player::add_objective(lua_State * L)

for which player the function was called. How do I do that?

I tried stealing some code, but

 Game & game = get_game(L);
 Player & p = get(L, game);

seems to give me an empty p.player_number()

[SirVer (sirver)]

no need to pass in the player_number.

 plrs[player_number]:add_objective(name, title, body)

adds a new objective that affects (only) player_number. If you want to have the same objective also affect other players, add a new optional parameter:

plrs[player_number]:add_objective(name, title, body, { player4, player3} )

Do not take player numbers, take player objects. You can get to them like this:

L_Player * c = *get_user_class<L_Player>(L, index_on_stack );

[GunChleoc (gunchleoc)]

> adds a new objective that affects (only) player_number.

Why does it appear in the objectives menu for all players then?

[SirVer (sirver)]

That is the desired property I suggest you work towards, not the current behavior.

Am 01.06.2014 um 20:28 schrieb GunChleoc <email address hidden>:

>> adds a new objective that affects (only) player_number.
>
> Why does it appear in the objectives menu for all players then?
>
> --
> You received this bug notification because you are subscribed to
> widelands.
> https://bugs.launchpad.net/bugs/1322473
>
> Title:
> Add Win conditions as an Objective
>
> Status in Widelands:
> In Progress
>
> Bug description:
> In non-scenario games, add the win conditions as an objective, so they
> can be easily reviewed later.
>
> Do we want to completely shift them away from the messages? In that
> case, the Tutorial text will need revising after the change.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands/+bug/1322473/+subscriptions

[GunChleoc (gunchleoc)]

Which brings me nack to my original question https://bugs.launchpad.net/widelands/+bug/1322473/comments/10:

When defining plrs[player_number]:add_objective(name, title, body), how do I find out *within* add_objective(name, title, body) what the plrs[player_number] is?

Only if I can get that working an I think about adding the same objective to multiple players of my choice.

[GunChleoc (gunchleoc)]

Sorry I overlooked the L_Player * c = *get_user_class<L_Player>(L, index_on_stack );

I'll have a go and let you know if I get stuck again.

[SirVer (sirver)]

The code in comment #10 Should do the trick. What do you mean by empty player_number? Most methods in l_player need to get to the underlying object. And the class itself should also contain a variable with the player number - cannot check this right now.

> Am 02.06.2014 um 13:28 schrieb GunChleoc <email address hidden>:
>
> Which brings me nack to my original question
> https://bugs.launchpad.net/widelands/+bug/1322473/comments/10:
>
> When defining plrs[player_number]:add_objective(name, title, body), how
> do I find out *within* add_objective(name, title, body) what the
> plrs[player_number] is?
>
> Only if I can get that working an I think about adding the same
> objective to multiple players of my choice.
>
> --
> You received this bug notification because you are subscribed to
> widelands.
> https://bugs.launchpad.net/bugs/1322473
>
> Title:
> Add Win conditions as an Objective
>
> Status in Widelands:
> In Progress
>
> Bug description:
> In non-scenario games, add the win conditions as an objective, so they
> can be easily reviewed later.
>
> Do we want to completely shift them away from the messages? In that
> case, the Tutorial text will need revising after the change.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands/+bug/1322473/+subscriptions

[SirVer (sirver)]

I think this bug is done with merging of the attached branch. The discussions about multiplayer objectives is interested, but does not really has anything to do with the OP of this bug?

If there is agreement, I suggest closing this and opening a new bug for multiplayer objectives?

[SirVer (sirver)]

I filed bug 1322473 to discuss multiplayer objectives. We can still reopen this one of course if there is more to it.

[GunChleoc (gunchleoc)]

IMO There is an application for it in the smugglers scenario - each player could have their individual objective changed once they reach a new island.

[GunChleoc (gunchleoc)]

This is the new bug: https://bugs.launchpad.net/widelands/+bug/1342281

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.