A way how to limit [scroll_to] to a side?

[SlowThinker]

The wiki doesn't indicate it is supported. Is any workaround possible?

[zookeeper]

What sense could that possible make? A location can't have a side, you know. If you look a couple of lines further you'll see a tag for scrolling to a unit, and units can have sides.

[Crendgrim]

Does [scroll_to] only apply to the side which turn currently is? If not, limiting this to a certain side could be useful in MP scenarios.


Crend

[SlowThinker]

Sorry for the confusion, zookeeper. Read next:

Crendgrim, scroll_to applies for all players. And would like it worked only for the player who invoked it (by a context menu for example).

[zookeeper]

Oh, right. Well, no, doesn't seem possible as such, but if you really really need it to work like that, there's a workaround: use select events to set side-specific variables and then an [if] to decide whether to scroll or not. Select events aren't triggered on remote clients, meaning that you can use them to have out of sync variables, but of course you need to make sure you only use those variables for things which don't cause OOS. Howevere, that won't work if you need to do the scrolling before each player has selected at least one of their units.

[SlowThinker]

Thank you.

Do you know why an automatically stored variable "this_side" is not maintained? Due to some architecture limitation?

In which case the different variables cause an OOS? Only if they affect the map state (terrain, units, gold...)? Saving works well?

[Anonymissimus]

Eyeyeyeyeyey.

use select events to set side-specific variables and then an [if] to decide whether to scroll or not. Select events aren't triggered on remote clients, meaning that you can use them to have out of sync variables, but of course you need to make sure you only use those variables for things which don't cause OOS. Howevere, that won't work if you need to do the scrolling before each player has selected at least one of their units.

Well, by definition you *do have* OOS as soon as any wml variable does not have the same value on all clients at the same time. The question is what that variable affects. If its only use is to decide whether to scroll or not to scroll I guess you won't get the typical OOS messages yes.
The "pedantic mode" mentioned on the easy codings page would probably not work with such a scenario then, it would report the OOS immediately.

I wonder whether there should be a way to execute complete wml events only on the active client like the select event, not only for this type of event. Afaik the synchronization is explicitely reponsible for the events being executed on all clients in parallel. It would confuse many multiplayer wml authors I guess.

Do you know why an automatically stored variable "this_side" is not maintained? Due to some architecture limitation

$side_number is the currently active side in all wml events which have an active side (almost all).
I can sense what you want - such a variable was an OOS variable immediately. And of course people wouldn't understand how they ought to use it or better, not use it; plenty of room for threads like this...
However you could create your this_side variable like this:

Code: Select all

[event]
    name=select
    first_time_only=no
    {VARIABLE this_side $side_number}
[/event]

No idea whether the first_time_... is needed. Since the select event is only executed on the client which is currently active ($side_number) and triggered it, $this_side should on each client contain the side_number of the client where this gamestate version is being held, after a complete game turn is over and all players selected at least one unit...

Saving works well?

Hm...no. The saves of each player contain their personal gamestate version. So a game reloaded by player $side_number will set the this_side variable above to that player's $side_number for all other clients too. The effect is gone after a full game turn is over again and each player did select at least one unit during his turn however (so you again have the OOS you want to have...)

[SlowThinker]

I wonder whether there should be a way to execute complete wml events only on the active client like the select event, not only for this type of event. Afaik the synchronization is explicitely reponsible for the events being executed on all clients in parallel. It would confuse many multiplayer wml authors I guess.
...
I can sense what you want - such a variable was an OOS variable immediately. And of course people wouldn't understand how they ought to use it or better, not use it; plenty of room for threads like this...

I believe it is very natural this_side should be available for the WML code.
this_side is not a gamestate information but an information about an environment in which the code runs (a similar type of information would be 'this side's player type': human/AI), and so there is a need to manage it different way (it is not supposed to be written to a savefile and must not be checked for OOS)

In fact this information (this_side) must be available to the internal Wesnoth code (C++, lua), otherwise the game window would be completely sychronized for all players. And I see no reason why WML should be different (Yes, if WML controlled only the gamestate then I agree WML could be deprived from this information. But WML doesn't only control the gamestate, but also controls the player's interface, which is supposed to be different for different sides.

edit: In order to avoid confusion: 'this side's player type'

[Sapient]

Do you know why an automatically stored variable "this_side" is not maintained? Due to some architecture limitation?

Because players can control more than one side?
Also, I find the proposed variable name misleading.
What you want is the side controller information.
Use [store_side] and check the controller attribute.

[SlowThinker]

Do you know why an automatically stored variable "this_side" is not maintained? Due to some architecture limitation?

Because players can control more than one side?

Nonono. The (WML) code has nothing with the players, but with sides.
Even if a player controls more sides, he gets only the point of view of the last side he has controlled.

Also, I find the proposed variable name misleading.
What you want is the side controller information.
Use [store_side] and check the controller attribute.

I don't want the side controller information.
'this_side' shall be a variable which that contains 1,2,3,4... on sides 1,2,3,4...

If I wanted 'this side's controller information' then I still would need this_side:

Code: Select all

[store_side] 
	side=$this_side
	variable=...
[/store_side] 

[Sapient]

It appears that you read my post, but responded without fully understanding it.
Please re-read it. The side controller information is (as I said) what you need.

There is already an automatically stored side_number variable.
http://wiki.wesnoth.org/SyntaxWML#Autom ... _Variables

[Anonymissimus]

You are writing as if you were a knowledgable wesnoth dev who knows how things work. You are not. Sapient is much more than you so don't attempt to prove him wrong or propose the way you want things to be or see them as the "official way" it should be.

Nonono. The (WML) code has nothing with the players, but with sides.
Even if a player controls more sides, he gets only the point of view of the last side he has controlled.

Well, my this_side variable as in the code above doesn't work in that case, its value varies between the side numbers the player controls.

Also, I find the proposed variable name misleading.
What you want is the side controller information.
Use [store_side] and check the controller attribute.

I don't want the side controller information.
'this_side' shall be a variable which that contains 1,2,3,4... on sides 1,2,3,4...

If I wanted 'this side's controller information' then I still would need this_side:

Code: Select all

[store_side] 
	side=$this_side
	variable=...
[/store_side] 

I think that you are kind of confused and don't know what you want.
Using the controller value from [store_side] is a good idea, it carries the information you want.
Please understand what I wrote about the values of side.controller in this post: http://forums.wesnoth.org/viewtopic.php ... 34#p490634 since by doing so you should understand Sapient's idea.

EDIT
So what you need to do is storing the side $side_number and then check whether side.controller equals human. If we are on the active client it will be and otherwise not. A player controlling 2 (more) sides will have the scrolling the number of sides he controls times, for each of them (is this correct English ? ).

EDIT2
Well I didn't mean one should never attempt to prove a dev wrong (suceeding at it gives great satisfaction ) but I'm a little afraid if people read things like that via forum search.

[Sapient]

Feel free to prove me wrong. We devs need to be humbled occasionally.

But, SlowThinker and I have a history of "talking past" one another. It is frustrating because I pride myself on clear and concise communication, and thus I dislike repeating myself. I will try to be more patient as well.

[SlowThinker]

(off topic: about the communication problems)

... I pride myself on clear and concise communication, and thus I dislike repeating myself. I will try to be more patient as well.

With all the respect it is not about the patience, but your not very clear comunication: just look at your 1st post in this thread:

1. you sent only unclear hints (compare with the very clear and still short Anonymissimus' explanation in the start of my next post)
2. you quoted my sentence ('why "this_side" is not maintained?') but then you tried to explain something different (how to detect an active client)

(but this is just my personal view of course)

Anyway thank you for the help, your idea seems to be the best answer to my original question.

[SlowThinker]

edit: a related info is here: question about out of sync errors


----------

So what you need to do is storing the side $side_number and then check whether side.controller equals human. If we are on the active client it will be and otherwise not.

Thank you, I understand now.
Anyway this way allows to detect the active client, but it doesn't fully replace this_side, which would be more powerful.

Well, my this_side variable as in the code above doesn't work in that case, its value varies between the side numbers the player controls.

You mean once a player selects with one of his sides, the select event is invoked with all his sides? Are you sure? I wouldn't expect such a behaviour.

A player controlling 2 (more) sides will have the scrolling the number of sides he controls times, for each of them

I am not sure whether I understand, let me rephrase:
Let us say a player controls side 1 and 2, and he uses BfW 1.9 with scroll_to_leader=no.
He scrolls with side 1 to a hex X (using the Sapient's trick), then he centers map to a hex Y and ends turn. Side 2 will start centered on the hex X. Correct?

The "pedantic mode" mentioned on the easy codings page would probably not work with such a scenario then, it would report the OOS immediately.

The pedantic mode would report OOS after any use of [store_side], wouldn't it?
So I think my idea the game information should be split to

• the game state (it is saved and checked for OOS)
• the game environment (automatically stored variables like this_side, controller, host_side: these variables are not saved and not checked for OOS)

is not so bad