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

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. ___

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

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

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

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:

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

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

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

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

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

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:

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

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:

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

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

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

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

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

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

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

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!

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

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

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

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

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

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

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

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] [bug #22983] non-ASCII characters in the user's path prevent BfW to launch

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!

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

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

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

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

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

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.

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

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

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

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

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

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-bugs] [bug #22988] any moveto event prevents units to attack

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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)

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

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

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

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

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

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

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

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 ___

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

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:

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

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] [bug #21800] a side with controller=null is shown in the game lobby

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

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

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

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

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)

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

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

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

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

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

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'

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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-bugs] [bug #21800] a side with controller=null is shown in the game lobby

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

  1   2   >