[Wesnoth-bugs] [bug #21708] observer doesn't see all non-team labels

[SlowThinker]

Follow-up Comment #2, bug #21708 (project wesnoth):

My recent tests:
1.10.5: the bug is present
1.12.2: same behaviour like the one of Wedge009 with 1.13.1, i.e. the bug is
not present 

So it looks the bug appeared with 1.10 only.  

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22774] Modify default behavior of [insert_tag] for empty variables

[SlowThinker]

Follow-up Comment #7, bug #22774 (project wesnoth):

I concur with tekelili. 

*Reason 1)*

This is how 
[insert_tag]   name=tag variable=my_var [/insert_tag]  
works:
It inserts the array my_var, but renames the array name from 'my_var' to
'tag'…

… with one exception: a non-existent array is processed a different way
And exceptions are bad in general. As tekelili pointed out, one must care
about them in the code.

*Reason 2)*
I believe the effect of insert_tag shall depend uniquely on the tag name and
the content of the variable (more precisely: of the array).
In other words, next sentence should be true:
_Let's have two instances of insert_tag. Their effect is equal if and only if
both 'name=' and the content of 'variable' are equal._

But the sentence is not true with the current insert_tag mechanism. Variables
'nothing' (in A) and 'something' (in B) are different, but insert_tag still
inserts an equal code:


# A)
{CLEAR_VARIABLE nothing}
[insert_tag]
name=redraw 
variable=nothing
[/insert_tag]

# B)
[set_variables]
name=something
mode=replace
[literal]
[/literal]
[/set_variables]
[insert_tag]
name=redraw 
variable=something
[/insert_tag]



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #23922] Reopening bug #22774 (insert_tag)

[SlowThinker]

Follow-up Comment #1, bug #23922 (project wesnoth):

so far all the debate went here:
https://gna.org/bugs/?22774
so I will send my comment there too

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22774] Modify default behavior of [insert_tag] for empty variables

[SlowThinker]

Follow-up Comment #8, bug #22774 (project wesnoth):

shadowmaster wrote:
_Do note that there are tags for which empty contents actually have a meaning
and effect, such as [redraw], [lock_view], and [unlock_view]. WML authors are
also able to use Lua to define their own parameterless tags._

I don't think this is a good argument.
You could still insert [redraw], see “Reason 2, code B” in my previous
post.
If you ask also “code A” inserts [redraw], then you ask a special
behaviour of the insert_tag mechanism:
You ask an exception that would allow you to insert a code, but not to have to
create the (empty) code first. (In general, you need to have a code, only then
you can insert it by insert_tag.)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21801] entering "Create Game" is slow

[SlowThinker]

Follow-up Comment #9, bug #21801 (project wesnoth):

Wedge009, I didn't test it after last changes that were aplied to  BfW 1.13 by
Chris Beck.

Did you run your test with 1.13 only? It might be useful to run the test with
1.12 too and to compare.

I guess one core of your Penryn is max. twice as fast as my Conroe_L, so the
process in 1.13 might be 3-times faster than in 1.12.

I don't know whether my Conroe-L 1.8 GHz is still operating, but if needed
then I could run tests with an Atom, which is even slower than Conroe-L. 

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21801] entering "Create Game" is slow

[SlowThinker]

Follow-up Comment #11, bug #21801 (project wesnoth):

I think this issue may be marked as "fixed".

I have run a test on Atom N570, 1.66 GHz:
BfW 1.12.4: less than 4s
BfW 1.13.1: less than 1s

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18693] Debug mode can be used in Network multiplayer

[SlowThinker]

Follow-up Comment #11, bug #18693 (project wesnoth):

also it should warn that a player joins a game with debug set to on.
{With 'debug on' a detailed info about enemy sides (gold ...) is accessible.)

___

Reply to this item at:

  http://gna.org/bugs/?18693

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #23579] save/reload process corrupts team_name

[SlowThinker]

Follow-up Comment #14, bug #23579 (project wesnoth):

1)
I don't know whether this point is clear:
The bug happens with *any scenario* (although it causes serious problems only
to scenarios that keep team-related data):

- start Hornshark Island
- red team is north
- save and reload
- red team is 1

2)
While the save/load process clearly triggers the bug, there are probably more
ways how to trigger it:
In my last game, team_name changed between autosaves of turn 1 and 2. The game
has not been reloaded.

___

Reply to this item at:

  http://gna.org/bugs/?23579

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21801] entering Create Game is slow

[SlowThinker]

Follow-up Comment #7, bug #21801 (project wesnoth):

off-topic:

I would like to have a system that would remind me this bug once I install BfW
1.13...

but I guess 
neither I can bookmark it 
nor bugs that are ready to test can get another color than red (like
yellow)...

___

Reply to this item at:

  http://gna.org/bugs/?21801

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #23579] save/reload process corrupts team_name

[SlowThinker]

Follow-up Comment #13, bug #23579 (project wesnoth):

simplifying 2a:
I use modify_side.team_name , but it doesn't change the value. It just keeps
the original one.

___

Reply to this item at:

  http://gna.org/bugs/?23579

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #23579] save/reload process corrupts team_name

[SlowThinker]

Follow-up Comment #9, bug #23579 (project wesnoth):

Do you want a real piece of WML code?

___

Reply to this item at:

  http://gna.org/bugs/?23579

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #23579] save/reload process corrupts team_name

[SlowThinker]

Follow-up Comment #7, bug #23579 (project wesnoth):

Yes, I am sure... except it might be caused by the save process. But I quickly
looked to the savefile and the team names seem to be ok.

(Initially I have got a bug report from Lich_Lord who claimed the bug effects
to the gameplay started in the very beginning.
But during all my tests the bug (and its effects to the gameplay) started
right after the reload process.)

___

Reply to this item at:

  http://gna.org/bugs/?23579

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #23579] save/reload process corrupts team_name

[SlowThinker]

Follow-up Comment #4, bug #23579 (project wesnoth):

1)
I tested MP games (both local and online) - all were affected.

2)
I tested a start of a SP campaign Heir to the Throne - it was not affected.

but...
3)
I reloaded a MP game as a SP game (Main menu/Load): both team_game and
user_team_game were corrupted (they both were set to 1, 2 ,3 ...)

to clarify:
if I reloaded a MP game as a MP game (Main menu/Multiplayer): only team_game
was corrupted, user_team_game was intact.

___

Reply to this item at:

  http://gna.org/bugs/?23579

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #23579] save/reload process corrupts team_name

[SlowThinker]

Follow-up Comment #5, bug #23579 (project wesnoth):

Anyway I think this is a serious bug, because it should hit all MP add-ons
that keep team-related data.

___

Reply to this item at:

  http://gna.org/bugs/?23579

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22984] sliders in the MP lobby cannot be controlled by a keyboard

[SlowThinker]

Follow-up Comment #2, bug #22984 (project wesnoth):

tested with 1.12.2, it works

___

Reply to this item at:

  http://gna.org/bugs/?22984

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22983] non-ASCII characters in the user's path prevent BfW to launch

[SlowThinker]

Follow-up Comment #9, bug #22983 (project wesnoth):

this bug doesn't appear with BfW 1.12.1

___

Reply to this item at:

  http://gna.org/bugs/?22983

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22988] any moveto event prevents units to attack

[SlowThinker]

Follow-up Comment #9, bug #22988 (project wesnoth):

In BfW 1.10 (also 1.8. and 1.6) a moveto event cancels nothing. BfW 1.12
(1.11?) is a turning point. (sorry that I didn't stress it in the original
post)

So yes, from a point of view of compatibility the default behaviour should not
change and a tag [cancel_action] seems better.

a note: this behaviour might affect not only moveto, but more events, like
exit_hex ... {?)

___

Reply to this item at:

  http://gna.org/bugs/?22988

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22988] any moveto event prevents units to attack

[SlowThinker]

Follow-up Comment #7, bug #22988 (project wesnoth):

 so enter/exit hex is unusable in this situation, and players will cry they
must split move+attack into two orders 
I don't know which situation you mean.
By situation I mean
_you need not to allow_undo, because your UMC is unable to restore things_

So I think we talk about the same problem: [allow_undo] has two effects, and
those should be split.
And yes, [dont_interrupt] would be a very simple solution. 

About the tag name: 
[dont_interrupt_order_queue] is more explanatory but it seems too long, and a
good explanation in the wiki would be satisfatory probably
I have one objection though: interrupt sounds like it will continue later,
maybe something like cancel is better? [dont_cancel] or [dont_cancel_orders]
...

(I will add more comments later)

___

Reply to this item at:

  http://gna.org/bugs/?22988

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22983] non-ASCII characters in the user's path prevent BfW to launch

[SlowThinker]

Follow-up Comment #4, bug #22983 (project wesnoth):

clarification of the last sentence in my previous post:

regardless I chose store user data in My DocumentsMy GamesWesnoth1.12 during
installation, 
the directory c:Documents and SettingsmásloDokumentyMy GamesWesnoth1.12 was
not created. 

___

Reply to this item at:

  http://gna.org/bugs/?22983

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22986] a whispered text is not always in the blue color

[SlowThinker]

Additional Item Attachment, bug #22986 (project wesnoth):

File name: wesnoth chat.png   Size:9 KB


___

Reply to this item at:

  http://gna.org/bugs/?22986

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22986] a whispered text is not always in the blue color

[SlowThinker]

Follow-up Comment #1, bug #22986 (project wesnoth):

the bug happens quite often: see the attached file as an example

___

Reply to this item at:

  http://gna.org/bugs/?22986

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22983] non-ASCII characters in the user's path prevent BfW to launch

[SlowThinker]

Follow-up Comment #6, bug #22983 (project wesnoth):

yes, but it is not much different from 
--config-dir e:My GamesWesnoth1.12
except no new directory is needed

Anyway i think it is rather a serious problem because all players with a
non-ASCII usename in Windows (e.g. all Chinese?) will run Wesnoth and nothing
will happen, not even a warning message. In BfW 1.10 the game started and
worked (although with some problems)


___

Reply to this item at:

  http://gna.org/bugs/?22983

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22988] any moveto event prevents units to attack

[SlowThinker]

Follow-up Comment #2, bug #22988 (project wesnoth):

Firstly, if this is not a bug then it is a new behaviour. I think UMC creators
should be warned (maybe here?
http://forums.wesnoth.org/viewtopic.php?f=21t=36057)

In most situations this makes sense because the movto event might have
changes the sitution

It might but it needn't to.
In my add-on I have a moveto event handler that does some work in the
background only (e.g. recalculates income, because it depends on position of
units), and so from the point of view of a player there is no such moveto
event (i. e. a player doesn't know about it). Therefore a player must be
surprised that suddenly the UI behaves differently.

an event with [allow_undo] should not cause this behaviour

Indeed, I just tested it.
It sounds nice ... yes, an UMC author should have under his control whether
the attack will be removed from the 'queue of orders' move+attack or not.
But what if the UMC author wants
[not to remove the attack] AND simultaneously [not to allow_undo]
?

You can answer that it won't happen, because ...  
situations where no new information was revealed to the player in the moveto
event handler (=A)
happen if and only if
the undo may be allowed (=B)
and it happens if and only if
there is no reason why the player would want to interrupt his order
move+attack (in other words not to attack (=C)

so mathematically we can say A = B = C
This idea sounds very reasonably.
(Also I noticed BfW 1.12 reflects this idea, because in 1.12 there is an
internal moveto event handler that checks whether an enemy unit was revealed
during the move and in that case the attack is canceled. (In BfW 1.10 the
attack was performed anyway.) )

But ... I think A = B is not fully true: there may be a situation where A
and not B.
Example: a unit consumes 'fuel' during movement, and the fuel is stored in a
variable. Then undo must be forbidden, because BfW offers no mechanism that
would allow to restore that variable after undo (at least I don't know about
that mechanism)

___

Reply to this item at:

  http://gna.org/bugs/?22988

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22988] any moveto event prevents units to attack

[SlowThinker]

Follow-up Comment #3, bug #22988 (project wesnoth):

slightly off topic: 
A mechanism that would support undo for UMC wouldn't be too complicated: two
new events would be needed:
a) an event name=undo_waypoint_created that would be fired just after BfW
created a new (way)point where the game may be undone to
b) an event name=undo_done that would be fired just after undo
(the waypoints would be numbered)

So the meaning of undo_waypoint_created would be:
wesnoth engine says to UMC: A new undo_waypoint nr. XY has been created. You
should backup your variables now, or you should start to register your next
actions so that you may undo them when needed
And the meaning of undo_done would be:
wesnoth engine says to UMC: An undo has been done, and the game returned to
the waypoint nr. YZ. You should restore your variables accordingly or you
should undo the actions you registered


___

Reply to this item at:

  http://gna.org/bugs/?22988

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22983] non-ASCII characters in the user's path prevent BfW to launch

[SlowThinker]

Follow-up Comment #1, bug #22983 (project wesnoth):

I am sorry for a mistake: The last sentence shall be
_italic_ BfW is launched correctly with a parameter --config-dir pointing to
a path without non-ASCII chars. _italic_

I wanted to say there is always a way how to launch BfW.





___

Reply to this item at:

  http://gna.org/bugs/?22983

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22984] sliders in the MP lobby cannot be controlled by a keyboard

[SlowThinker]

URL:
  http://gna.org/bugs/?22984

 Summary: sliders in the MP lobby cannot be controlled by a
keyboard
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun 23 Nov 2014 01:11:48 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12.0
Operating System: Windows XP

___

Details:

Sliders of Gold and Income in the MP lobby cannot be controlled by a
keyboard.
It is not easy to do it with a mouse only.

(in BfW 1.10 a player could do it by both mouse and keyboard)





___

Reply to this item at:

  http://gna.org/bugs/?22984

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22986] a whispered text is not always in the blue color

[SlowThinker]

URL:
  http://gna.org/bugs/?22986

 Summary: a whispered text is not always in the blue color
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun 23 Nov 2014 01:37:48 PM UTC
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12.0
Operating System: Win XP

___

Details:

First time I received a whisper after the installation of BfW 1.12.0, the
text
_whisper: XYZ text_
was white only.

Though I don't know how to recreate the bug: even after a restart of BfW any
received whisper was blue.






___

Reply to this item at:

  http://gna.org/bugs/?22986

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22983] non-ASCII characters in the user's path prevent BfW to launch

[SlowThinker]

Follow-up Comment #3, bug #22983 (project wesnoth):

I just tried to run Wesnoth 
path_to_my_wesnothwesnoth.exe --config-dir  e:/máslo/wesnoth/Wesnoth1.12/
and it worked.

In order to reproduce, use a Windows user name with non-ASCII characters (e.g.
máslo).
And during the Wesnoth install choose store user data in My DocumentsMy
GamesWesnoth1.12

---
I wonder about one thing:
during a fresh install of BfW 1.12.0 no c:Documents and
SettingsmásloDokumentyMy GamesWesnoth1.12 directory has been created.


___

Reply to this item at:

  http://gna.org/bugs/?22983

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22988] any moveto event prevents units to attack

[SlowThinker]

URL:
  http://gna.org/bugs/?22988

 Summary: any moveto event prevents units to attack
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun 23 Nov 2014 11:01:17 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12.0
Operating System: Windows XP

___

Details:

In BfW a player can order his unit to attack a target unit that is not
adjacent. 
(in a detail:
1) he clicks on his unit
2) he moves a mouse cursor over a hex that is adjacent to the target
3) he clicks on the target )

But this is not possible if the scenario contains a moveto event. In this case
the attacking unit stops besides the target and must be re-ordered.

How to recreate: play this scenario:


[multiplayer]
id=00 test no_direct_attack 
name=_00 test no_direct_attack
description=_ testing no_direct_attack
map_data={multiplayer/maps/2p_Den_of_Onis.map}

[event]
name=moveto
first_time_only=no
[label]
x,y=$unit.x,$unit.y
text=moved
[/label]

[/event]
[/multiplayer]





___

Reply to this item at:

  http://gna.org/bugs/?22988

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #22983] non-ASCII characters in the user's path prevent BfW to launch

[SlowThinker]

URL:
  http://gna.org/bugs/?22983

 Summary: non-ASCII characters in the user's path prevent BfW
to launch
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun 23 Nov 2014 06:40:44 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12.0
Operating System: Windows XP

___

Details:

BfW is closed prior any window is created, and the content of stderr.txt is:


Automatically found a possible data directory at E:/Games/Battle for Wesnoth
1.12.0
20141123 07:14:52 error filesystem: Invalid UTF-8 string'C:\Documents and
Settings\máslo\Dokumenty' 
Caught general exception:
boost::filesystem::path codecvt to wstring: error


'E:/Games/Battle for Wesnoth 1.12.0' was my install directory.

BfW is launched correctly with a parameter --config-dir pointing to a
non-ASCII path. 




___

Reply to this item at:

  http://gna.org/bugs/?22983

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #20, bug #21966 (project wesnoth):

@ any Wesnoth dev:

so what exactly happened? Are next lines correct?

- In turn 3 Blop's client allowed a too long move (for an unknown reason). 
- The move has been sent via the network (and it was stored in the replay)
- The Quietude's client received the too long move and cut it. But it didn't
raise any exception/error/OOS at this moment.
- The OOS appeared next turn (turn 4), when the clients expected the unit to
stand on different locations and the unit moved.

And in case the lines above are correct, is the behaviour of the Quietude's
client intended or is it a bug? (I mean the Quietude's client ignored the
problem in turn 3)

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #13, bug #21966 (project wesnoth):

I meant: at which turn/side did you start the reloaded game (and got no
problems anymore)?

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #15, bug #21966 (project wesnoth):

1. 
Blop, do you remember whether your militia ended at 5,51 or 5,52 in turn 3?

2.
I just realized the save of your reloaded game won't help.
(Details:
I downloaded your reloaded game from 
http://replays.wesnoth.org/1.10/20140423/Conquest-_Surdmark_(telep.,_long_dist.)_+__(requires_Conquest_Minus_or_AE)_Turn_9_(11274).gz
(there are problems with the replay, but it has nothing common with our
problem: it happens because of https://gna.org/bugs/?19603)

The file still contains the too long move of a green militia in turn 3, and
the OOS in turn 4:

[command]
sent=
[move]
x=5,4,3,2
y=51,50,51,50
[/move]
[/command]
[command]
sent=yes
[speak]
id=server
message=Quietude reports out of sync errors.
[/speak]
[/command] 

... but it didn't spoil your game because it happened prior to the game
start.

)

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #17, bug #21966 (project wesnoth):

I am confused:

it looks Blop was the hosts:

mp_game_title=Blops Partie


it looks Quietude was the host, at least when the game ended:

[command]
[speak]
id=server
message=Quietude has left the game.
[/speak]
[/command]

[command]
[speak]
id=server
message=Blop takes control of side 1.
[/speak]
[/command]

[command]
[speak]
id=server
message=Blop takes control of side 4.
[/speak]
[/command]

[command]
[speak]
id=server
message=Blop takes control of side 5.
[/speak]
[/command]
[/replay]

Explanation: Side 5 is an AI side, and the host should control it.
Blop might disconnect during the game and so lose the control, but a search of
a string disco yields no result. Or is there another string that one needs
to look for?

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #19, bug #21966 (project wesnoth):

a militia needs 2 moves on a bridge.

see comment #15, the OOS happened before you teleported.
I guess the OOS was caused when Quietude's client didn't find a militia on the
source hex of a movement - 5,51 (it expected the militia at 5,52)

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #6, bug #21966 (project wesnoth):

well the reason seems to be that somewhere an impossible move was issured.
Which usualy causes an OOS.

Maybe you didn't read my original submission in a detail. The first problem
happened prior to the OOS:
- it looks until turn 3 of the green side everything is OK
- *turn 3 of the green side appears OK if you watch the replay visually, but
[move] in the savefile doesn't correspond to the visual replay*
- only in turn 4 of the green side the OOS is fired.


(More info can give you the original player who controlled the green side: his
name is Blop, he is registered in the Wesnoth forums, and I just sent him a
link to this gna page.

But I suspect he won't give you more info than me:
I think his turn 3 appeared to be OK, exactly as my replay of turn 3 appeared
OK.
)

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21882] Scenario with only leaderless AI side ends with defeat as soon as it starts

[SlowThinker]

Follow-up Comment #13, bug #21882 (project wesnoth):

@involution

 I have corrected the part about modify_side
http://wiki.wesnoth.org/DirectActionsWML#.5Bmodify_side.5D 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.

___

Reply to this item at:

  http://gna.org/bugs/?21882

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #8, bug #21966 (project wesnoth):

@Anonymous:
My save is from replays.wesnoth.org, and I think players didn't have when they
informed me about the problem.

It is also possile that ... this is related to your addon. 
I checked all use of u.max_moves and manipulation with u.moves:
In one moment of turn 1 I reset moves to max_moves in a moveto event. But then
the event is removed.
It could cause a problem only if BfW was buggy and would resuscitate the
mentioned moveto event.

@Blop (the green player):
You wasn't the host, right?
Did you mention any problem prior the OOS in turn 4?
You have no your own save of the game?


___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #11, bug #21966 (project wesnoth):

Blop, the game you reloaded (and that was not corrupted) was from which turn?

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21882] Scenario with only leaderless AI side ends with defeat as soon as it starts

[SlowThinker]

Follow-up Comment #10, bug #21882 (project wesnoth):

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]

___

Reply to this item at:

  http://gna.org/bugs/?21882

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #14, bug #21800 (project wesnoth):

the problem continues in 1.11.15

___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #15, bug #21800 (project wesnoth):

My previous post is invalid.

And I can confirm the problem described in comment #12 has been patched in BfW
1.11.15

___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21882] Scenario with only leaderless AI side ends with defeat as soon as it starts

[SlowThinker]

Follow-up Comment #7, bug #21882 (project wesnoth):

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~


___

Reply to this item at:

  http://gna.org/bugs/?21882

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21882] Scenario with only leaderless AI side ends with defeat as soon as it starts

[SlowThinker]

Follow-up Comment #8, bug #21882 (project wesnoth):

*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.)


___

Reply to this item at:

  http://gna.org/bugs/?21882

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21882] Scenario with only leaderless AI side ends with defeat as soon as it starts

[SlowThinker]

Follow-up Comment #5, bug #21882 (project wesnoth):

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)

___

Reply to this item at:

  http://gna.org/bugs/?21882

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21882] Scenario with only leaderless AI side ends with defeat as soon as it starts

[SlowThinker]

Follow-up Comment #4, bug #21882 (project wesnoth):

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. 

___

Reply to this item at:

  http://gna.org/bugs/?21882

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #12, bug #21800 (project wesnoth):

Maybe I found out when the bug happens: It happens in the debug mode.
And it sounds reasonable that in the debug mode players can control also sides
with 'allow_player=no' (or 'controller=null'? All occurences I found had both
'allow_player=no' and 'controller=null').

But I still see a little bug there: The team of the side with
'allow_player=no'/'controller=null' is automatically changed to the side1's
team, and maybe there are more changes in the side's properties.


___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19603] Broken replays at replays.wesnoth.org

[SlowThinker]

Follow-up Comment #4, bug #19603 (project wesnoth):

The next text is partially off topic, and a feature request.

Think about situations where a player/observer replays
a) from the very beginning (that happens in an off-line replay, from a saved
game)
b) from the last load point (that happens in an on-line replay, from server's
data)

A replay from the very beginning might be useful also for an on-line observer
(in fact from another Wesnoth player I got a question how to do it).
A replay from the last load point might be useful also for an offline replay:
it would allow PBEM games ...

(... but only if one could watch the replay from a Point of view of side 2,
3 ,4 ... I don't understand why there is the limitation Team 1/Each Team/Full
Map;
the choice of a viewpoint would be useful also online - a player who
disconnected could rejoin safely and without the blindfold mode, and in the
meantime the other player could continue his turn.)

___

Reply to this item at:

  http://gna.org/bugs/?19603

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21882] Scenario with only leaderless AI side ends with defeat as soon as it starts

[SlowThinker]

Follow-up Comment #3, bug #21882 (project wesnoth):

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]


___

Reply to this item at:

  http://gna.org/bugs/?21882

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

URL:
  http://gna.org/bugs/?21966

 Summary: OOS - unfound location for source of movement
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Thu Apr 24 12:49:21 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.x
Operating System: unknown

___

Details:

Summary: an impossible movement of a unit is registered and saved into a
replay, and next turn it causes an OOS error unfound location for source of
movement

Look at this replay
http://replays.wesnoth.org/1.10/20140423/Conquest-_Surdmark_(telep.,_long_dist.)_+__(requires_Conquest_Minus_or_AE)_Turn_4_(11243).gz
and this move of the greenside in turn 3:

[command]
sent=
[move]
x=7,6,6,6,5,5,5,5
y=57,56,55,54,54,53,52,51
[/move]
[/command]

This move was impossible because Spearman had 7 movepoints and the cost of
x,y=6,55 was  2 movepoints.

The replay is correct visually, and the unit ends at 5,52 in place of the
impossible hex 5,51.

But in turn 4 of the green side this mismatch causes this OOS error:
unfound location for source of movement: 5,51 - 2,50

A note: I encountered this OOS warning during past years in various Wesnoth
games, although it was very sparse.




___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #18, bug #21776 (project wesnoth):

Correction of a sentence:

wesnoth.synchronize_choice: Recovers a WML table that was computed on one
client only or WAS STORED IN A REPLAY 

(i tried to use italic in place of capitals and failed)

___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21966] OOS - unfound location for source of movement

[SlowThinker]

Follow-up Comment #2, bug #21966 (project wesnoth):

 that rather ssems to be a bug during the original game than in the replay.
Yes, the OOS was reported in the game already (and again in the replay).

i sometimes have such errors when the unit got a quick trait in the
original game
The unit that caused OOS was resilient+strong. 
(In fact these traits were not full traits:
In Conquest Minus I clear all traits from a variable before [unstore_unit] is
applied, but Game Inspector still shows them and one of them ('healthy') keeps
its effect. No trait is shown to players in the right-side panel.
)

___

Reply to this item at:

  http://gna.org/bugs/?21966

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #17, bug #21776 (project wesnoth):

Especialy in a mp game, a controller can also change during the game without
reloading. 
Inside of a mp game, the hosting player who changes the controller from/to AI
can take a measure before, by a context menu.
And yes, a new event controller_change would help.


 So the input must stay within turn 2. 
But i think the turin 2 event is inside turn 2? 
I understand now.
I thought it worked in a start event only. I missed words or also in every
other synced event.
It seems powerful, for example it allows private (or group) diplomacy talks or
an exchange of items in FFA games. The only problem is if only 2 players are
talking then the other ones must wait.


there is an option using sync_choice whcih is replay save even in 1.12 (maybe
even 1.10)
I think I understand: Naturally the argument function of synchronize_choice is
not called in replays, and rather the synchronized return table is used. So
synchronize_choice not only
sychronizes the table among the clients (this is useful after a select event
that changes the game state), 
but also 
sychronizes the replay with the real game (this is useful after a reload or
select event that changes the game state)

(I was confused by this sentence in the wiki
wesnoth.synchronize_choice: Recovers a WML table that was computed on one
client only or _was_ _stored_ _in_ _a_ _replay_
that probably tries to explain it but was unclear to me.
)

But I think the main problem would be to find an appropriate moment of the
synchronization of was_reloaded_synced. A moveto event needn't be sufficient
because the synchronization may be needed earlier.
So I would prefer to sychronize in game_events.on_event. Would it work?
game_events.on_event is onyl mpsave (mpsave = replaysave) when the fired
event is a mpsave event
Do you mean on_event is called only before mpsafe events? Or it is called also
before select events and so it may cause OOS if I am not careful?
Also I am a bit confused by the term mpsafe. I expected in BfW pre-1.11.13 one
must distinguish three types of events:
- select: it is fired on one client only
- attack_end: it is fired on all clients, but [message][text_input] is not
synchronized
- moveto: it is fired on all clients, and [message][text_input] is
synchronized
?

___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #14, bug #21776 (project wesnoth):

(I agree this is a minor cause, probably not worth to work on it. Wesnoth has
much more serious problems. :) Like the lua environment that is not saved.
)

Also becasue i currently believe that relaoding should not change the
gamestate

I understand that philosophy, but the problem is the WML/lua system is far
from perfect, and there are situations in which it is useful (see comment #7,
the text that come to my mind).

And from a philosophical point of view, don't forget the save/load process
doesn't lead to an identical situation, since the controller may change. 
An example scenario: WML may help AI to cheat

 IMO a replay should be an exact replay. 
there are other events aswell which arent fired in the replay (select ... )
I see.
But still ... it is expected a select event won't be fired during a replay
because it is not synchronized. It is natural to expect that any stuff will be
replayed iff it is synchronized.
Also select events behave consistently in a replay. A preload event is fired
sometimes, sometimes it is not. (The situation would be more clean if the
events were distinguished, name=preload,save_and_reload )

Conquest Minus:
which could maybe the be solved by moving all the make some input in the
turn 2 event. But maybe you meant player actions (move, attack) while i
thought you meant right click menus, [message][option] and similar by input. 
Yes, I meant [message][option]. But in turn 1 players play the game, and in
turn 2 they decide whether the start is balanced enough. So the input must
stay within turn 2.


___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #12, bug #21776 (project wesnoth):

so you want to use things like [option][message] or luas sync_choice during
preload events?

I was rather theoretizing.
Hmm ... it could still work if a preload event just detected a reloaded game
and then first moveto event (or select event or
wesnoth.game_events.on_event(?)) arranged a menu for a player.

Idk whether it helps you wit your original problem ...

It wouldn't help me: In fact I need to 'return' from the end of turn 3 to the
begining of turn 2.
(Maybe if I want to avoid a game reload then I can join two scenarios ... )

Anyway this is not a serious issue for me.
I object mostly from a general point a view: IMO a replay should be an exact
replay.

___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #10, bug #21800 (project wesnoth):

My mistake: Sulla's ruins contains a side with 'allow_player=no'.

Now I have no idea what triggers/removes the bug. I got the bug again (just
for scenarios with 'allow_player=no'), I removed the file with preferences but
the bug stayed. I reinstalled BfW 1.11.11 and so far I am not able to trigger
the bug.

___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #8, bug #21800 (project wesnoth):

I attached my preferences.
But I suspect the preferences needn't be the triger that caused the bug. Maybe
only the removal of preferences forced BfW to reset things and to clear the
bug effect.

(file #20388)
___

Additional Item Attachment:

File name: preferences.slowthinkerSize:44 KB


___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #5, bug #21800 (project wesnoth):

I loaded the file from the user data directory: data/add-ons
This is my screenhot:
http://imgur.com/zHLpLfh

notice user_team_name=Neutrals is ignored

(Off topic: This bug seems to be system-specific
http://forums.wesnoth.org/viewtopic.php?f=4t=37835
)

___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #6, bug #21800 (project wesnoth):

Result of more tests:

The problem has nothing common with allow_player=
This is a screenshot of a standard scenario:
http://imgur.com/rUDXxnz

It looks it was the file wesnoth_user_data_directory/preferences that caused
the problem:
My BfW 1.11.11 behaved correctly until I copied 'preferences' from BfW 1.10. 
From that point any game had one additional side (see screenhots).
Once I removed 'preferences' the bug dissapeared.
Then I was unable to reproduce it with any 'preferences', even those from BfW
1.10.



___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #3, bug #21800 (project wesnoth):

Currently controller=null will just make the side be assigned empty by
default, afaik.

Yes, and I think it is a better behaviour than in 1.10. 
controller= should not interfere with allow_player= IMO

Are you sure that this isn't working? Can you provide a test file?

For me next code shows side 2 as 'Empty' with BfW 1.11.11:


#textdomain wesnoth-multiplayer

# wmllint: local spelling Kah Ruuk Oni Onis
[multiplayer]
id=test_multiplayer_Den_of_Onis
name=test allow_player=no 2p — Den of Onis
map_data={multiplayer/maps/2p_Den_of_Onis.map}

{DEFAULT_SCHEDULE}
{DEFAULT_MUSIC_PLAYLIST}

[side]
[ai]
villages_per_scout=8
[/ai]
side=1
canrecruit=yes
controller=human
team_name=south
user_team_name= _ teamname^South
fog=yes
[/side]
[side]
side=2
no_leader=yes   
team_name=Neutrals  
user_team_name=Neutrals 
team_lock=true
canrecruit=no
controller=null 
allow_player=no
#   hidden=yes
[/side]
[/multiplayer]




___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

URL:
  http://gna.org/bugs/?21800

 Summary: a side with controller=null is shown in the game
lobby
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sat Mar 15 17:19:21 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.11
Operating System: Windows XP

___

Details:

Wesnoth 1.10 didn't show such a side in the list of sides.




___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21801] entering Create Game is slow

[SlowThinker]

URL:
  http://gna.org/bugs/?21801

 Summary: entering Create Game is slow
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sat Mar 15 23:46:15 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.11
Operating System: Windows XP

___

Details:

Entering the window Create Game is very slow, regardless where one enters it
from:
It happens even if a player is in the window Configure Game already, and he
presses Back.





___

Reply to this item at:

  http://gna.org/bugs/?21801

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #1, bug #21800 (project wesnoth):

Now I noticed allow_player= should control whether the side is shown in the
game lobby. 
(In Wesnoth 1.10 controller=null prevents the side is shown too, for some
reason unknown to me)

Anyway in Wesnoth 1.11 allow_player=no is ignored.

___

Reply to this item at:

  http://gna.org/bugs/?21800

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #10, bug #21776 (project wesnoth):

 a savefile can serve as the starting point of the game and can offer
choices 
hmm i still don't understand what you mean. 

Normally players choose a scenario, set its parameters in the game lobby or in
the game beginning, and play.
Similarly they could choose a savefile, a preload event would allow them to
set game paramenters, and they would play.

For example Conquest Minus generates random unit spawns. If a spawn is
interesting, more players might want to play it, but with different settings
than the original players.
A preload event could offer players to chanhge settings.
This is doable by a context menu too, but many Wesnoth players don't know
about custom menu items or don't expect it.


___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19603] Broken replays at replays.wesnoth.org

[SlowThinker]

Follow-up Comment #2, bug #19603 (project wesnoth):

tested again with 1.10.7 (but I guess the bug is not related to a Wesnoth
version)

this game has been reloaded:
http://replays.wesnoth.org/1.10/20140312/2p__Den_of_Onis_Turn_2_(10571).gz

the final and corrupted replay:
http://replays.wesnoth.org/1.10/20140312/2p__Den_of_Onis_Turn_3_(10573).gz

___

Reply to this item at:

  http://gna.org/bugs/?19603

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #7, bug #21776 (project wesnoth):

 but in the game the lua variables are deleted during reload, in the replay
that doesnt happen. And the prelaod events are normaly executed to compensate
that.

Oh, I didn't know that.

thats also possible with the current implementation. save variables in
wesnoth.game_events.on_save and restore them in preload events. 

you mean in game_events.on_load? 
game_events.on_load is not skipped in replays like preload events?
and wiki confuses me - game_events.on_load is called also when a game starts
or only when a sevefile is loaded?

i don't think fireing preload events again would cause problems though.

If you don't delete the Lua environment concurrently then it can cause
problems.  
- An initialization of a Lua structure in a preload event can use 'if
something == nil then'
- In a non-preload event one can check whether the game has been reloaded by
testing a Lua variable

  i think throwing them away just to rebuild it in a replay would waste of
cputime

IMHO to save cpu time by complicating things and asking for problems is not a
good idea.
I would say it even if I didn't see any concrete issues, but here are some
more that come to my mind:

- a savefile can serve as the starting point of the game and can offer
choices
- a specific side controller may be required to play the game or may determine
a mode of the game
- sometimes a preload event is a way how to bypass a Wesnoth bug:
-- in past a status of disallow_end_turn was not saved in a savefile
-- if [variables] didn't exist then this bug could be prevented in a reload
event: https://gna.org/bugs/?19258


___
Conquest Minus:

hm i still dont understand how do you put the input you gained during that
one turn in the save of the first turn. do you use [set_global_variable] ? 

The players' input is not a part of the game. In the input players can veto
the game. So the input determines whether the game will continue (and will be
reloaded) or a new game will start. 
I need players do the input simultaneously, without any knowledge of the input
of the other player - this is why a Wesnoth chat cannot be used.


___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #2, bug #21776 (project wesnoth):

There is no OOS in the game. An OOS may occur in the replay though, because
the replay is not synchronized with the real game.

This is because preload events are skipped in the replay.
In the example below, after the 'preload' event runs 2nd time, the variable
'reloaded_game' has a different value in the replay and in the game.

(To be very concrete, in Conquest Minus I allow a mode where players can
estimate their spawns while their units have zero movepoints. If they agree to
play then they reload a game, the add-on understands the game has been
reloaded (see the variable reloaded_game in the code below), and their units
get full movepoints back.)

___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

Follow-up Comment #4, bug #21776 (project wesnoth):

I named it a bug because I expected the replay should replay the game exactly
how it went in reality.

 people would have to check wether their envoronment is already loaded in
every preload event then.

I cannot imagine how any problem could happen then.
If the real game had no problem and the replay is equal to the real game then
the replay must be problem-free too, musn't it?

___
Problems in Conquest Minus
This is a minor problem for Conquest Minus. I created a walkaround, which is
not perfect from several points of view, but it is sufficient.

is there a special reason why they have to reload a game to agree and not
pressing a right click menu button to do so?

In Conquest Minus, after the point of the first save and before the reload,
the game continues one more turn so that the players can make some input. If
the game continued (without a reload) then there would be one additional dummy
turn, which would increase a natural turn numbering. This is why the game must
be reloaded.

__
Other problems
There are other scenarios in which you expect a reload event not only loads
constants (Lua constants), that couldn't be saved, but does a real job:
example:

Lua variables are not saved. Imagine you transform a table into a WML
container (this transformation would be somewhat opposite to
wesnoth.get_variable), so that it is saved. Then a reload event loads this
table from the WML container.
This way you can work a full-featured way with Lua tables, and you are not
limited to WML tables only.

___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21776] Replays of reloaded games skip 'preload' event handlers

[SlowThinker]

URL:
  http://gna.org/bugs/?21776

 Summary: Replays of reloaded games skip 'preload' event
handlers
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun Mar  9 20:43:26 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: Windows XP

___

Details:

Imagine this situation:

1. a game is started
2. 'preload' events are fired
3. the game continues
4. the game is saved and reloaded
5. 'preload' events are fired 2nd time
6. the game continues
7. the game is saved and replayed

The replay will skip point 5. Therefore OOS may occur during the replay.

An example:

The code bellow will behave this way:
in a game: it will write 'reloaded_game=no' before the game reload and
'reloaded_game=yes' after the reload
in a replay:
it will always write 'reloaded_game=no'


[event]
name=prestart
first_time_only=yes
{VARIABLE start_passed yes}
[/event]
[event]
name=preload
first_time_only=no
[if]
{VARIABLE_CONDITIONAL start_passed not_equals yes}
[then]
# this is a very start of the game
{VARIABLE reloaded_game no}
[/then]
[else]
# this is a reloaded game
{VARIABLE reloaded_game yes}
[/else]
[/if]
[/event]
[event]
name=side turn
first_time_only=no
[chat]
speaker=Debug info
message=reloaded_game=$reloaded_game
[/chat]
[/event]






___

Reply to this item at:

  http://gna.org/bugs/?21776

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21723] [item] team_name= doesn't work correctly

[SlowThinker]

URL:
  http://gna.org/bugs/?21723

 Summary: [item] team_name= doesn't work correctly
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Tue Feb 25 22:12:22 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: Windows XP

___

Details:

An item should be visible just to sides of team_name:
http://wiki.wesnoth.org/InterfaceActionsWML#.5Bitem.5D
But it is visible to all teams, and just during turns of team_name.

How to reproduce:
just use a simple code like 


[item]
x=2
y=3
image=scenery/rune1.png
team_name=Team 1
[/item] 





___

Reply to this item at:

  http://gna.org/bugs/?21723

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[SlowThinker]

Follow-up Comment #12, bug #21405 (project wesnoth):

Concerning blindfold replays:
I guess the observer cannot chat / see the chat until he gets the side
control?
The player and especially the host should be warned that a blind observer is
coming, probably in the chat area.
And if you don't mind to make things more complicated you could add a textbox
near the 'blind replay' checkbox in the game lobby. It would serve for one
chat message, like I am Ice, I was orange.

___

Reply to this item at:

  http://gna.org/bugs/?21405

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21708] observer doesn't see all non-team labels

[SlowThinker]

URL:
  http://gna.org/bugs/?21708

 Summary: observer doesn't see all non-team labels
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sat Feb 22 10:48:24 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: any

___

Details:

This is between a bug and a feature request:

In case there are both a non-team and a team labels on a given hex, a player
sees only the team label.
An observer shares the sight with the player, except he doesn't see team
labels. Therefore he sees nothing.

I believe he should see the non-team label.





___

Reply to this item at:

  http://gna.org/bugs/?21708

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[SlowThinker]

Follow-up Comment #3, bug #21405 (project wesnoth):

I think you can undroid an AI in the middle of its turn, so the UI is not
completely blocked.

--
Another related feature request, but probably more complicated to implement:
Sometimes a player quits 
from a FFA game, or 
from a 2 vs 2 game, and the remaning player of the team doesn't want to
control 2 sides.
Then the game with a free slot should be distinguished in the game lobby (the
game color in the lobby should be for example dark green, in order to
differentiate from games that didn't start yet), and the game should continue
until the 'free slot side' gets control; then it would get into the
'superidle' mode.

So from the player's point of view there would be
a) a slot assigned to the host, but idle (= the original feature request)
b) an unassigned slot (and so idle) (= the previous paragraph)

___

Reply to this item at:

  http://gna.org/bugs/?21405

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[SlowThinker]

Follow-up Comment #6, bug #21405 (project wesnoth):

Is it really so complicated to hide the replay from the re-joining player? 

(I know there is still a problem that if other players decide to continue
their turns, the re-joining player will miss the news.)

___

Reply to this item at:

  http://gna.org/bugs/?21405

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[SlowThinker]

Follow-up Comment #8, bug #21405 (project wesnoth):

I don't mean skipping replays but hiding them. The client would show only the
turn / side number of the replay in the upper/side bars.

___

Reply to this item at:

  http://gna.org/bugs/?21405

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21661] fog is not refreshed for allied sides

[SlowThinker]

URL:
  http://gna.org/bugs/?21661

 Summary: fog is not refreshed for allied sides
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun Feb 16 15:25:03 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: Windows XP

___

Details:

Fog is not refreshed for allied sides, and therefore it is possible to watch
an enemy movement even if it should be covered by fog.

How to reproduce:
1) On 3 Wesnoth clients start a 3-player multiplayer game. Side1 and side2 are
in one team, side3 is their enemy.
2) Side2 moves so that it reveals a unit Some_unit of side3, then withdraws,
so that Some_unit is covered by fog again. 
At the end of turn side2 doesn't see Some_unit, but side1 still sees
Some_unit: its fog was not refreshed.
3) Side2 ends its turn and side3 moves Some_unit. Side2 doesn't see the
movement, because it is hidden in fog, but side1 sees it.

Scenarios can fix this bug by executing
[redraw] side=$side_number [/redraw]
, for example at 'side turn end'.




___

Reply to this item at:

  http://gna.org/bugs/?21661

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21659] Lua: 'location_set:empty' works as not_empty

[SlowThinker]

Follow-up Comment #3, bug #21659 (project wesnoth):

Not that it is very important, but ...

I think to be empty is something much more primitive than not to be empty.
I guess you will hardly find an implementation of sets with a function
is_not_empty in place of is_empty.

___

Reply to this item at:

  http://gna.org/bugs/?21659

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21659] Lua: 'location_set:empty' works as not_empty

[SlowThinker]

URL:
  http://gna.org/bugs/?21659

 Summary: Lua: 'location_set:empty' works as not_empty
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sat Feb 15 20:43:04 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: any

___

Details:

The method name corresponds to the wiki description:
Returns true if the set is empty.
(http://wiki.wesnoth.org/LuaWML:Location_set#location_set:empty)

but the effect is opposite: it returns true if the set is NOT empty.




___

Reply to this item at:

  http://gna.org/bugs/?21659

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21486] Team label clears a non-team label

[SlowThinker]

URL:
  http://gna.org/bugs/?21486

 Summary: Team label clears a non-team label
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Wed Jan 15 23:19:56 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: Windows XP

___

Details:

How to reproduce:
1) A player of team1 creates a non-team label
2) Later on that hex a player of team2 creates a team label
3) = From a point of view of team1 the non-team label dissapears and the hex
has no label

A note: Apparently the engine allows team and non-team labels can coexist:
If a team label is created first, then the other team creates a non-team
label, then both teams see the label they created themselves.




___

Reply to this item at:

  http://gna.org/bugs/?21486

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21459] In MP a player can get the sight of the other team

[SlowThinker]

Follow-up Comment #1, bug #21459 (project wesnoth):

typo correction:

PlayerC and any observer sees the chat of playerB colored by the color of SIDE
2

___

Reply to this item at:

  http://gna.org/bugs/?21459

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21459] In MP a player can get the sight of the other team

[SlowThinker]

URL:
  http://gna.org/bugs/?21459

 Summary: In MP a player can get the sight of the other team
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Tue Jan  7 04:10:47 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: Windows XP

___

Details:

The bug happens when it is the host's turn and he quits/disconnects. The bug
doesn't happen with 1 vs 1, only with 2 vs 2 and above.

How to reproduce:
start a 2 vs 2 map: the hosting player (playerA) controls side 1 (required)
and side 4 (not required for the bug reproduction, it may be side 2 or side
3), both sides in one team; the other player (playerB) controls the other
team, sides 2 and 3
an observer (playerC) comes to the game
it is turn 1, side 1: playerA quits
playerB becomes the host and passes the control to playerC
the system says: 
igoring illegal whiteboard data, sent from user 'playerB' to team
'team_name'
now playerB's client thinks he controls side 4: his sight switches to the
other team, and he sees his own chat colored by the color of side 4.
playerC and any observer sees the chat of playerB colored by the color of team
2

I don't know whether whiteboard planning on/off affects the bug appearance.
The bug was tested when PlayerB had whiteboard planning off.

This bug may be related: 
https://gna.org/bugs/?func=detailitemitem_id=18655



___

File Attachments:


---
Date: Tue Jan  7 04:10:48 2014  Name:
4p_—_Blue_Water_Province_Turn_1_bug_control.gz  Size: 13kB   By: slowthinker
In the chat area the save explains what happened.
http://gna.org/bugs/download.php?file_id=19699

___

Reply to this item at:

  http://gna.org/bugs/?21459

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18655] Whiteboard Error message while playing multiplayer without whiteboard turned on

[SlowThinker]

Follow-up Comment #3, bug #18655 (project wesnoth):

This bug may be related:
https://gna.org/bugs/index.php?21459

___

Reply to this item at:

  http://gna.org/bugs/?18655

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[SlowThinker]

Follow-up Comment #1, bug #21405 (project wesnoth):

an additional note:
Even if there is an observer in the game, and the hosting player passes him
the side control, the hosting player sees the opponent's side for a short
period of time - when removing illegal message... is shown in the chat area
(it didn't happen in BfW 1.8, but happens in 1.10)

___

Reply to this item at:

  http://gna.org/bugs/?21405

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21405] Don't force players to cheat in multiplayer (after disconnect)

[SlowThinker]

URL:
  http://gna.org/bugs/?21405

 Summary: Don't force players to cheat in multiplayer (after
disconnect)
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Tue Dec 31 12:52:21 2013
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: any
Operating System: any

___

Details:

If a player disconnects then the host must choose what to do. He can
- pass the control to any player (including himself)
- pass the control to an observer
- end the game

Imagine a 1 vs 1 game: if there is no observer then the host is forced to see
the position of his opponent (and so to cheat).

Solution 1 (preferred):
add an option that allows to put the side in an 'idle' mode
Solution 2:
add an option that allows to save the game (but then the host must reload the
game)




___

Reply to this item at:

  http://gna.org/bugs/?21405

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21397] saving+reloading may cause a side's turn is not initialized

[SlowThinker]

URL:
  http://gna.org/bugs/?21397

 Summary: saving+reloading may cause a side's turn is not
initialized
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun Dec 29 21:13:09 2013
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.7
Operating System: Windows XP

___

Details:

It happens in a multiplayer and may be reproduced this way:

1. Create a 2-player multiplayer game
2. During a turn of player1, player2 pauses the game by invoking any dialog
3. player1 ends his turn and saves the game.
4. After the game is reloaded, it is the beginning of player2's turn, but his
units have no movement and no income was added to his gold.

related thread: http://forums.wesnoth.org/viewtopic.php?f=4t=34729p=564824




___

Reply to this item at:

  http://gna.org/bugs/?21397

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21398] FormulaAI: wrong substraction

[SlowThinker]

URL:
  http://gna.org/bugs/?21398

 Summary: FormulaAI: wrong substraction
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun Dec 29 21:22:40 2013
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.5
Operating System: Windows XP

___

Details:

if the result of substraction is between -1 and 0 then it is reverted to its
absolute value.
For example
5-5.5 yields 0.500

related thread: http://forums.wesnoth.org/viewtopic.php?f=4t=38595




___

Reply to this item at:

  http://gna.org/bugs/?21398

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19682] full-featured tunnels

[SlowThinker]

URL:
  http://gna.org/bugs/?19682

 Summary: full-featured tunnels
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Tue May  1 05:51:56 2012
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: any
Operating System: any

___

Details:

In BfW 1.10 [tunnel] allows to define a relation to be adjacent, but from
point of view of movement only. Therefore a player doesn't see through tunnels
and tunnels may be easily blocked.

Therefore to be adjacent should be extended to all aspects - to vision,
combat and ZOCs.
(also it would allow cylindric maps for example.)

This feature has been discussed here:
http://forums.wesnoth.org/viewtopic.php?p=526679#p526679




___

Reply to this item at:

  http://gna.org/bugs/?19682

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19625] Modal dialog causes a side's control is problematic

[SlowThinker]

URL:
  http://gna.org/bugs/?19625

 Summary: Modal dialog causes a side's control is problematic
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sun Apr  8 18:05:50 2012
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.1
Operating System: Win XP Pro

___

Details:

In a MP game that runs on a MP server, a modal dialog may cause errors if it
is open when host passes side's control to another player.

How to reproduce:
1. Start a 2p game on a MP server, side1: player1 (host), side2: player2.
2. During side1's turn player2 pauses his client by opening a dialog
3. Player1 ends his turn
4. Player1 takes control of side2: ':control 2 player1'. 
He gets a message it is now player1's turn 
5. Player2 closes the dialog. 
He gets a message it is now player2's turn
Both players get a message 'server Removing illegal command 'init_side'
from: player2. Current player is: player1.'

In the case above the game may continue probably,
but I encountered also cases where player2 was able to end turn of side2 and
to continue to play. Then error messages continued with any action (like
'Removing illegal command 'end_turn' ') .




___

Reply to this item at:

  http://gna.org/bugs/?19625

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19603] Broken replays at replays.wesnoth.org

[SlowThinker]

Follow-up Comment #1, bug #19603 (project wesnoth):

It looks my original submission was wrong about the way how to reproduce, and
the fact whether the hosting player disconnected or not has nothing to do with
the bug:
The bug happens if the game has been reloaded.

Summary of my current understanding about the bug:
http://forums.wesnoth.org/viewtopic.php?p=525335#p525335

--
The bug has a common point with this bug: https://gna.org/bugs/?19258


___

Reply to this item at:

  http://gna.org/bugs/?19603

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19603] Broken replays at replays.wesnoth.org

[SlowThinker]

URL:
  http://gna.org/bugs/?19603

 Summary: Broken replays at replays.wesnoth.org
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Fri Mar 30 18:01:23 2012
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Replays
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.1
Operating System: Win XP Pro

___

Details:

A replay gets broken if the hosting player disconnected.

How to reproduce:
1. start a MP game on the official server
2. disconnect the hosting player (for example kill wesnothd.exe) 
3. end the game
4. check the replay at replays.wesnoth.org

More details here:
http://forums.wesnoth.org/viewtopic.php?f=4t=36499




___

Reply to this item at:

  http://gna.org/bugs/?19603

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #18693] Debug mode can be used in Network multiplayer

[SlowThinker]

Follow-up Comment #9, bug #18693 (project wesnoth):

grickit wrote:
 the game suddenly OOSes — because BillyBob had debug mode on and decided
to make a yeti.
 ...
 We should not have any official features or in-game-options that cause
OOS. Only errors and bad WML should do that.

Such OOS is not a problem of the debug mode: The yeti creation should not
cause OOS, it should be rather distributed to other clients, like any other
player's action.
But I fully agree the server should announce if someone uses the debug mode.

___

Reply to this item at:

  http://gna.org/bugs/?18693

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19562] Savefile's name is ignored in some situations

[SlowThinker]

URL:
  http://gna.org/bugs/?19562

 Summary: Savefile's name is ignored in some situations
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Mon Mar 19 01:12:40 2012
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.1
Operating System: Win XP Pro

___

Details:

A player is offered to save his multiplayer game after it ends an unusual way
(the player disconnects, oos happens...). The player can type a savefile's
name, but it is not used, and the default file name is always used.

How to reproduce:
1. start a MP game (for example via localhost)
2. lose the connection (for example kill wesnothd.exe)
3. type any filename in the textbox
4. the filename won't be used




___

Reply to this item at:

  http://gna.org/bugs/?19562

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19563] Replay doesn't show all units when it should

[SlowThinker]

URL:
  http://gna.org/bugs/?19563

 Summary: Replay doesn't show all units when it should
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Mon Mar 19 01:19:07 2012
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Replays
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.1
Operating System: Win XP Pro

___

Details:

If a player chooses 'point of view: full map' then no fog is shown, but still
units that would be under fog are not shown on the main map. 
All units are shown on the minimap though.




___

Reply to this item at:

  http://gna.org/bugs/?19563

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19544] Failed to show a dialog, which doesn't fit on the screen

[SlowThinker]

URL:
  http://gna.org/bugs/?19544

 Summary: Failed to show a dialog, which doesn't fit on the
screen
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Tue Mar 13 15:36:53 2012
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Graphics
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.10.0
Operating System: Win XP Pro

___

Details:

The bug has ben observed with a Wesnoth's textbox:
If  '[message] [text_input] label=' is too long and the Wesnoth window is not
wide enough then an error message is shown (see below) and the game is ended.

It might be just a different effect of this bug:
https://gna.org/bugs/index.php?19237
also because the error message is identical with both bugs:

An error due to possibly invalid WML occurred
The error message is :
Failed to show a dialog, which doesn't fit on the screen.
When reporting the bug please include the following error message :
src\gui\widgets\window.cpp:940 in function 'layout' found the following
problem: Failed to size window; wanted size 844,126 available size 694,676
screen size 896,706.

You can reproduce the bug if you run the attached scenario in a smaller
window.

a note: the textbox is very wide and doesn't reflect max_length, and so it
occupies a lot of window width.



___

File Attachments:


---
Date: Tue Mar 13 15:36:54 2012  Name: test_bug_textinput.zip  Size: 435B   By:
slowthinker

http://gna.org/bugs/download.php?file_id=15364

___

Reply to this item at:

  http://gna.org/bugs/?19544

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19237] A dialog is not resized with the BfW's window

[SlowThinker]

Follow-up Comment #1, bug #19237 (project wesnoth):

The bug might be just a different effect of this bug: 
https://gna.org/bugs/index.php?19544

___

Reply to this item at:

  http://gna.org/bugs/?19237

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19258] Errors in replays of reloaded games - a superfluous container

[SlowThinker]

Follow-up Comment #5, bug #19258 (project wesnoth):

SlowThinker wrote:
If you want to test then use Conquest Minus 3.0.14 and lower. The new
version 3.0.15 prevents the bug to take any effect.

There is another issue with 3.0.14, so please for testing use Conquest Minus
3.0.13:
http://forums.wesnoth.org/viewtopic.php?p=513932#p513932

___

Reply to this item at:

  http://gna.org/bugs/?19258

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19258] Errors in replays of reloaded games - a superfluous container

[SlowThinker]

Follow-up Comment #4, bug #19258 (project wesnoth):

SlowThinker wrote:
You can also test the full procedure (start a
game...save...load...save...replay) with any Conquest Minus map if you
download Conquest Minus from the 1.8 add-on server

If you want to test then use Conquest Minus 3.0.14 and lower. The new version
3.0.15 prevents the bug to take any effect.

___

Reply to this item at:

  http://gna.org/bugs/?19258

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19258] Errors in replays of reloaded games - a superfluous container

[SlowThinker]

URL:
  http://gna.org/bugs/?19258

 Summary: Errors in replays of reloaded games - a superfluous
container
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Mon Jan  9 11:30:41 2012
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Replays
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.13
Operating System: Win XP Pro

___

Details:

The problem:
Replays of some scenarios produce OOS errors if the game was saved/reloaded
in the middle.

Rectification:
The savefile contains a container replay_start.variables which causes the
errors and is apparently superfluous: If the container replay_start.variables
is deleted then replays work well.

More details here: http://forums.wesnoth.org/viewtopic.php?f=4t=33973




___

Reply to this item at:

  http://gna.org/bugs/?19258

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19258] Errors in replays of reloaded games - a superfluous container

[SlowThinker]

Follow-up Comment #2, bug #19258 (project wesnoth):

I mostly tested SaveGame+MainMenu/Load/ShowReplay_checked, but the problem
seems to be identical also with SaveReplay: again the file contains the
replay_start.variables container and OOSes are reported.

how-to-reproduce:
1) Load any game, save immediately, and you will see the new tag
replay_start.variables has been added to the savefile: I consider it a buggy
behaviour, such saves should be very similar.

2a) If you want to see a real impact on the replay, load the file I just
attached (it is the 2nd save) in BfW 1.9.3 with the procedure
MainMenu/Load/ShowReplay_checked. 
2b) You can also test the full procedure (start a
game...save...load...save...replay) with any Conquest Minus map if you
download Conquest Minus from the 1.8 add-on server (let me know if you need it
for 1.9)

Which scenarios are affected:
* the scenarios with variables that aren't cleared before they are used,
because the replays don't start with an empty space of variables, but with
variables set to their value in the moment of the 1st save: 
** the arrays may have more items
** the strings may be longer: imagine {VARIABLE aux $aux+asdf}
** etc.
* sometimes also the random generator is in a different status during the
replays and so yields different random numbers than in the original game. This
problem happened with Conquest Minus - you can see the ownerships of villages
(they are distributed randomly) in the original game and in the replay are
different. (But I usually didn't get this problem with very simple scenarios
which produced random numbers only.)





(file #14777)
___

Additional Item Attachment:

File name: Replay_bug_save2.7zSize:46 KB


___

Reply to this item at:

  http://gna.org/bugs/?19258

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19258] Errors in replays of reloaded games - a superfluous container

[SlowThinker]

Follow-up Comment #3, bug #19258 (project wesnoth):

By Which scenarios are affected
I mean Which scenarios have a real impact on the replay.
(It looks ANY scenario creates the replay_start.variables tag and then tries
to use these variables on the replay start.)

In case I didn't explain clearly how the bug emerged:
* It looks the author of the bug stored the variables in the point of the
reload, because he thought he would start the replay from that point.
* then he started the replay from the very beginning, but still applied the
variables from the reload-point.

___

Reply to this item at:

  http://gna.org/bugs/?19258

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs