[Wesnoth-bugs] [bug #23893] attempt to add an [event] with empty id=, ignoring

Update of bug #23893 (project wesnoth): Status:None => Invalid ___ Follow-up Comment #1: You seem to have at least one [unit_type][event] without an id=. For such [event]s id= is

[Wesnoth-bugs] [bug #23893] attempt to add an [event] with empty id=, ignoring

Update of bug #23893 (project wesnoth): Assigned to:None => anonymissimus ___ Reply to this item at: <http://gna.org/bugs/?23893> ___

[Wesnoth-bugs] [bug #24020] almost (?) reproducible complex crash involving the whiteboard

URL: <http://gna.org/bugs/?24020> Summary: almost (?) reproducible complex crash involving the whiteboard Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Di 03 Nov 2015 21:53:58 UTC Categor

[Wesnoth-bugs] [bug #24020] almost (?) reproducible complex crash involving the whiteboard

Follow-up Comment #1, bug #24020 (project wesnoth): Screenshot mentioned in opening post is here: http://postimg.org/image/nzll318jz/ ___ Reply to this item at:

[Wesnoth-bugs] [bug #23658] unhighlighting combined enemy reach

URL: http://gna.org/bugs/?23658 Summary: unhighlighting combined enemy reach Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Tue 23 Jun 2015 09:20:25 PM UTC Category: Bug Severity: 3

[Wesnoth-bugs] [bug #23639] Activating/deactivating modifications is done via a confusing extra button

URL: http://gna.org/bugs/?23639 Summary: Activating/deactivating modifications is done via a confusing extra button Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Mon 08 Jun 2015 10:13:49 PM UTC

[Wesnoth-bugs] [bug #23638] Clicking cancel when waiting for players to join steps back to second game creation screen

URL: http://gna.org/bugs/?23638 Summary: Clicking cancel when waiting for players to join steps back to second game creation screen Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Mon 08 Jun 2015 10:01:07 PM UTC

[Wesnoth-bugs] [bug #23638] Clicking cancel when waiting for players to join steps back to second game creation screen

Update of bug #23638 (project wesnoth): Item Group: None of the others = Multiplayer ___ Reply to this item at: http://gna.org/bugs/?23638 ___ Message sent

[Wesnoth-bugs] [bug #21905] Crash when replaying animation and clicking button

URL: http://gna.org/bugs/?21905 Summary: Crash when replaying animation and clicking button Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Fri 11 Apr 2014 03:17:46 PM UTC Category: Bug

[Wesnoth-bugs] [bug #18921] Peculiar segfault

Follow-up Comment #4, bug #18921 (project wesnoth): Trying to reproduce this bug https://gna.org/bugs/?21905 sometimes triggers the assertion AI added. ___ Reply to this item at: http://gna.org/bugs/?18921

[Wesnoth-bugs] [bug #21865] Random Campaign crash

Follow-up Comment #4, bug #21865 (project wesnoth): At the point which you reference it was probably already clear that there is an engine bug and how it can be triggered. Generally, you should first report any bugs triggered by UMC to the respective UMC author, who needs to nail down the cause

[Wesnoth-bugs] [bug #21768] segfault in lua_function= filter

Follow-up Comment #4, bug #21768 (project wesnoth): The file is still missing. Perhaps some technical problem on your side ? I don't know wanything about security, but I don't think we need to worry. What I called direct pointers are lua userdata objects, instances of the class lua_unit from

[Wesnoth-bugs] [bug #21768] segfault in lua_function= filter

Follow-up Comment #5, bug #21768 (project wesnoth): That being said, I seem to recall using lua_function= to modify the gamestate anyway. For instance, just setting a variable or so are safe things. So it could break backwards compatibility. The most dangerous things I can think of are adding or

[Wesnoth-bugs] [bug #21804] unexpected death animation

URL: http://gna.org/bugs/?21804 Summary: unexpected death animation Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Sun 16 Mar 2014 08:14:09 PM UTC Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #21768] segfault in lua_function= filter

Follow-up Comment #2, bug #21768 (project wesnoth): Reading the other bug report hardens my assumption. You can perhaps get around the problem by not using any of those lua functions which add or remove units from the unit_map (wesnoth.put_unit, wesnoth.extract_unit). wesnoth.get_unit(s) return

[Wesnoth-bugs] [bug #21158] gamemap class doesn't handle empty files

Follow-up Comment #2, bug #21158 (project wesnoth): This seems to be introduced by rev 52641/d75e320e5aa4b801cb9d0f4ef6722e1d4f37635a I don't think so. It should already have happened before that; the default I added (allow_invalid = true) just matches the previous behavior. I was working on the

[Wesnoth-bugs] [bug #21158] gamemap class doesn't handle empty files

Update of bug #21158 (project wesnoth): Assigned to: anonymissimus = None ___ Reply to this item at: http://gna.org/bugs/?21158 ___ Nachricht

[Wesnoth-bugs] [bug #21772] uninitialized read in about.cpp line 288

Update of bug #21772 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #2: Fixed in 4c6cad1327c18a63632d2a7aa5ca86e1386a6bd5

[Wesnoth-bugs] [bug #21772] uninitialized read in about.cpp line 288

URL: http://gna.org/bugs/?21772 Summary: uninitialized read in about.cpp line 288 Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Sa 08 Mär 2014 02:12:55 UTC Category: Bug Severity: 4

[Wesnoth-bugs] [bug #21772] uninitialized read in about.cpp line 288

Follow-up Comment #1, bug #21772 (project wesnoth): It's currently (commit cfc38796d44b04d613315187a317e1f8702a1556) line 288: int max_text_width = text_rect.w; ___ Reply to this item at: http://gna.org/bugs/?21772

[Wesnoth-bugs] [bug #21724] problems with automatic ellipsing

URL: http://gna.org/bugs/?21724 Summary: problems with automatic ellipsing Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Wed 26 Feb 2014 12:01:33 AM UTC Category: Bug Severity: 5

[Wesnoth-bugs] [bug #21724] problems with automatic ellipsing

Follow-up Comment #1, bug #21724 (project wesnoth): There was also another problem when changing a hero to a leader so it was looking for ellipse-hero-leader or something, but I could work around that by modifying the unit's ellipse=. ___

[Wesnoth-bugs] [bug #21724] problems with automatic ellipsing

Update of bug #21724 (project wesnoth): Severity: 5 - Blocker = 4 - Important ___ Reply to this item at: http://gna.org/bugs/?21724 ___ Message sent

[Wesnoth-bugs] [bug #21467] end iterator deref when launching test scenario

URL: http://gna.org/bugs/?21467 Summary: end iterator deref when launching test scenario Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Sa 11 Jan 2014 00:27:18 GMT Category: Bug

[Wesnoth-bugs] [bug #21291] Mystery Campaign fails to load map

Follow-up Comment #1, bug #21291 (project wesnoth): Is there a way to get more verbose errors ? Or some other way I can help solve this ? Yes, launching wesnoth from commandline while passing --log-debug=all as a parameter. This is likely a bug in the addon, not the engine. As a shot in the

[Wesnoth-bugs] [bug #17244] Sometimes all the keyboard shortcuts stop responding

Follow-up Comment #9, bug #17244 (project wesnoth): I recently encountered a shortcuts not working bug for the first time. It was in a networked MP game with another player (he was true remote host, false remote host would be another wesnoth instance on same computer); becoming observer and

[Wesnoth-bugs] [bug #21127] problems with wml_menu_item class

Follow-up Comment #2, bug #21127 (project wesnoth): My debugger behaves differently depending on whether there are references at least. This doesn't neccessarily mean they make a difference as the debugger often plays tricks with me. Even if you don't get a crash, gdb should be able to display

[Wesnoth-bugs] [bug #21118] Can no longer get to local multiplayer as of yesterday

Follow-up Comment #4, bug #21118 (project wesnoth): Fixed in 5239b36793f0a40f0bfd1c330d50ebf148f11ca9. ___ Reply to this item at: http://gna.org/bugs/?21118 ___ Nachricht gesendet von/durch

[Wesnoth-bugs] [bug #21118] Can no longer get to local multiplayer as of yesterday

Update of bug #21118 (project wesnoth): Status:None = Fixed ___ Reply to this item at: http://gna.org/bugs/?21118 ___ Nachricht

[Wesnoth-bugs] [bug #21127] problems with wml_menu_item class

URL: http://gna.org/bugs/?21127 Summary: problems with wml_menu_item class Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Di 10 Sep 2013 18:41:21 GMT Category: Bug Severity: 4

[Wesnoth-bugs] [bug #21020] Segmentation fault

Update of bug #21020 (project wesnoth): Assigned to:None = jamit ___ Reply to this item at: http://gna.org/bugs/?21020 ___ Nachricht

[Wesnoth-bugs] [bug #20923] Intermittent crash (runtime error) when using planning mode

Update of bug #20923 (project wesnoth): Assigned to:None = gabba ___ Follow-up Comment #1: forum thread: http://forums.wesnoth.org/viewtopic.php?f=4t=39000 Well, your screenshots show

[Wesnoth-bugs] [bug #20836] harm_unit doesnt fire advance event when experience=yes

Follow-up Comment #3, bug #20836 (project wesnoth): Then don't I say. ___ Reply to this item at: http://gna.org/bugs/?20836 ___ Nachricht gesendet von/durch Gna! http://gna.org/

[Wesnoth-bugs] [bug #20719] next_scenario= not correctly read

Follow-up Comment #7, bug #20719 (project wesnoth): I wouldn't mind just forgetting about this feature then. Showing it if and only if the map is not shrouded sounds okay. ___ Reply to this item at: http://gna.org/bugs/?20719

[Wesnoth-bugs] [bug #20719] next_scenario= not correctly read

Follow-up Comment #3, bug #20719 (project wesnoth): The original intent is pretty irrelevant I'd say. Important is what seems to be the best right now. And well, based on what wou write, we should perhaps declare the bug a feature and mention it in the wml syntax changes thread. (And move

[Wesnoth-bugs] [bug #20861] Modifications

Follow-up Comment #3, bug #20861 (project wesnoth): Note that I assigned it to you since you are probably best suited to fix it, but that you are rather unlikely to be responsible for the problem, so you could just throw it at the feet of whoever committer who is. ;)

[Wesnoth-bugs] [bug #20861] Modifications

Follow-up Comment #1, bug #20861 (project wesnoth): PYAM's author here. I can reproduce the problem using trunk 1.11.4-234-g8e74136 and PYAM umc-dev r16518. However, I remember that this error (mandatory wml child missing) did not appear the last time I tested it. This must have been roughly at

[Wesnoth-bugs] [bug #20861] Modifications

Update of bug #20861 (project wesnoth): Assigned to:None = lipk ___ Reply to this item at: http://gna.org/bugs/?20861 ___ Nachricht

[Wesnoth-bugs] [patch #3751] remove files on Windows so --revert and conversion can proceed (without Error 183, file already exists)

Update of patch #3751 (project wesnoth): Assigned to: esr = anonymissimus Open/Closed:Open = Closed ___ Follow-up Comment #1: duplicate of https

[Wesnoth-bugs] [bug #20841] Linking error when using CMake

Update of bug #20841 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #4: fixed in commit 1e766c2246f11e74880fb263f6d8e4233b2b082c

[Wesnoth-bugs] [bug #20853] In scenarios, if a side starts with gold=0 it is 100

Follow-up Comment #4, bug #20853 (project wesnoth): This was just some help for a developer trying to fix this bug. Not directed at you and nothing you need to understand. ___ Reply to this item at: http://gna.org/bugs/?20853

[Wesnoth-bugs] [bug #20853] In scenarios, if a side starts with gold=0 it is 100

Follow-up Comment #1, bug #20853 (project wesnoth): Perhaps it was introduced by commit by0d2eefaa8fa87d2861d0ed1011574fda5495 as I didn't notice it in my campaign recently (about 08.04.2013, with probably a recent trunk built) but now I do.

[Wesnoth-bugs] [bug #20853] In scenarios, if a side starts with gold=0 it is 100

Follow-up Comment #2, bug #20853 (project wesnoth): wrong commit hash... 1.11.2-288-g0d2 ___ Reply to this item at: http://gna.org/bugs/?20853 ___ Nachricht gesendet von/durch Gna!

[Wesnoth-bugs] [bug #20846] The use of 'save_id' and 'persistent=yes' seems to crash the game.

Follow-up Comment #2, bug #20846 (project wesnoth): Reproduction with mainline wml is always very much preferred over UMC. ___ Reply to this item at: http://gna.org/bugs/?20846 ___

[Wesnoth-bugs] [bug #20841] Linking error when using CMake

Update of bug #20841 (project wesnoth): Assigned to:None = mordante ___ Follow-up Comment #3: Assigning to you mordante as the cmake maintainer. Note that this contains a patch apparently

[Wesnoth-bugs] [patch #3847] Added support of notifications for Windows

Update of patch #3847 (project wesnoth): Open/Closed:Open = Closed ___ Follow-up Comment #6: This patch thread continued as a pull request: https://github.com/wesnoth/wesnoth-old/pull/13

[Wesnoth-bugs] [patch #3914] Using scoped_ptr in unit class (refactor)

Follow-up Comment #1, patch #3914 (project wesnoth): Umm, pls don't duplicate in this direction I'd say. Pull requests are certainly the better option. ___ Reply to this item at: http://gna.org/patch/?3914

[Wesnoth-bugs] [patch #3846] Fixed bug #20734: Default 100 gold is applied when gold isn't specified in scenario.cfg

Follow-up Comment #7, patch #3846 (project wesnoth): It is the leader's id, not the side one's. Sides don't normally have an id, unless the wml author explicitely specifies a save_id. We could make specifying a non-empty save_id for persistent sides mandatory. If it's not given, stderr message

[Wesnoth-bugs] [patch #3846] Fixed bug #20734: Default 100 gold is applied when gold isn't specified in scenario.cfg

Follow-up Comment #5, patch #3846 (project wesnoth): Did you notice that meanwhile ayne committed a different fix, probably without knowing about this ? (commit 0d2eefaa8fa87d2861d0ed1011574fda5495) I think one can't rely on at least one of [side]save_id= or [side]id= not being empty. The

[Wesnoth-bugs] [bug #20800] Simply do not start : Segmentation Error (core dumped)

Follow-up Comment #1, bug #20800 (project wesnoth): Hello, with the report in this form, there's nothing that could be done about it since there's nothing where one could start. With acceptable effort you can do these: -attach a backtrace, see

[Wesnoth-bugs] [bug #20800] Simply do not start : Segmentation Error (core dumped)

Update of bug #20800 (project wesnoth): Severity: 5 - Blocker = 3 - Normal ___ Reply to this item at: http://gna.org/bugs/?20800 ___ Nachricht

[Wesnoth-bugs] [patch #3899] Httt 06_siege_of_elensefar micro_Ai iplemetation

Follow-up Comment #1, patch #3899 (project wesnoth): As I've played this scenario *many* times, and also the bottleneck defense scenario in mattsc's AI mod demo, I don't think that it is a good idea to use this micro ai there. Firstly, I somehow doubt it works well with that map as there are

[Wesnoth-bugs] [bug #16148] Assertion failed: !wml_triggered

Follow-up Comment #8, bug #16148 (project wesnoth): Both jamit's and natewr's test cases are good and reproduce for me using 1.11.2-263-g931e1f9 I think that they cover the same bug. The attack code taking place before the last breath/die event adds random results in random.cpp; probably for

[Wesnoth-bugs] [bug #20765] Game crashing when custom unit appears

Follow-up Comment #2, bug #20765 (project wesnoth): Note the last post in that thread; the triggering part of the wml is the terrain string. ___ Reply to this item at: http://gna.org/bugs/?20765

[Wesnoth-bugs] [patch #3742] Inner variable for adjacent filter in abilities WML and TROW distract fix

Follow-up Comment #1, patch #3742 (project wesnoth): I'm strongly against adding any more such variables, since they will suffer from the same problem like $teleport_unit, namely premature variable substitution if the ability is added to the unit using an [object]. The problems are described in

[Wesnoth-bugs] [patch #3846] Fixed bug #20734: Default 100 gold is applied when gold isn't specified in scenario.cfg

Follow-up Comment #1, patch #3846 (project wesnoth): I also added gold=100 for SoF:1 for clarity. I rather wouldn't want that (from the UMC author point of view). Using conventions in mainline tends to outsource workload onto UMC authors, since their addons have the more unusual wml then. Only

[Wesnoth-bugs] [bug #20734] player starts with 0 gold in SoF

URL: http://gna.org/bugs/?20734 Summary: player starts with 0 gold in SoF Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Do 11 Apr 2013 16:52:09 GMT Category: Bug Severity: 3

[Wesnoth-bugs] [bug #20716] Descriptions should no longer include the name as the first line. is too vague

Follow-up Comment #4, bug #20716 (project wesnoth): Yes, I found another ability which I had overlooked that way. Hopefully they're gone now. Still unclear why it did look for the string upon clicking some different unit. ___ Reply to this

[Wesnoth-bugs] [bug #20716] Descriptions should no longer include the name as the first line. is too vague

Follow-up Comment #2, bug #20716 (project wesnoth): I think I eliminated all abilities/weapon specials with this case, but the message still seems to come at random when clicking on units. It did happen even in a case when all of the units on the map with an ability or special were freshly

[Wesnoth-bugs] [bug #20718] wesnoth does not start - error filesystem: Trying to open file with empty name.

Follow-up Comment #1, bug #20718 (project wesnoth): As for the empty stack, perhaps you compiled a release build. IIRC you need to pass -DCMAKE_BUILD_TYPE=Debug to cmake. ___ Reply to this item at: http://gna.org/bugs/?20718

[Wesnoth-bugs] [bug #20719] next_scenario= not correctly read

URL: http://gna.org/bugs/?20719 Summary: next_scenario= not correctly read Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Sa 06 Apr 2013 19:01:50 GMT Category: Bug Severity: 3

[Wesnoth-bugs] [bug #20719] next_scenario= not correctly read

Follow-up Comment #1, bug #20719 (project wesnoth): The problem can also be reproduced with HttT::17_Scepter_of_Fire by removing the [scenario][generator][settings]next_scenario= key/value. Thus, 1.11 apparently reads only this entry. It is redundant to [scenario]next_scenario=. What do we do if

[Wesnoth-bugs] [bug #20564] Persistent crash when loading my own replays in 1.11.1

Follow-up Comment #7, bug #20564 (project wesnoth): Some of the replays from my campaign crash with that assertion as well. Probably the same bug. I tried to figure out something the crashing replays/scenarios have in common, to no avail. I can confirm that trying to load a save as a replay from

[Wesnoth-bugs] [bug #20564] Persistent crash when loading my own replays in 1.11.1

Update of bug #20564 (project wesnoth): Release: 1.11.1 = 1.11.1, 1.11.2-110-g90316ec Operating System: Windows Vista = Win Vista, xp ___ Reply to this item at:

[Wesnoth-bugs] [bug #20718] wesnoth does not start - error filesystem: Trying to open file with empty name.

Update of bug #20718 (project wesnoth): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #3: Okay. Closing as

[Wesnoth-bugs] [bug #20716] Descriptions should no longer include the name as the first line. is too vague

Follow-up Comment #1, bug #20716 (project wesnoth): The error message should include that exact name it complains about. ___ Reply to this item at: http://gna.org/bugs/?20716 ___ Nachricht

[Wesnoth-bugs] [bug #20676] gold carryover broken in DiD::Endless Night

Update of bug #20676 (project wesnoth): Status:None = Fixed Assigned to:None = ayne ___ Follow-up Comment #5: Done in

[Wesnoth-bugs] [bug #20659] error message when mother unit, child unit and _initial.cfg in same folder

Follow-up Comment #3, bug #20659 (project wesnoth): If the reason why I had to put that explicit loading in there was a bug in the first place, I don't mind removing it. However, I should know some BfW version from when on it has been save to guard the explicit loading by #ifver, since 1.10.x

[Wesnoth-bugs] [bug #20676] gold carryover broken in DiD::Endless Night

Follow-up Comment #2, bug #20676 (project wesnoth): To sum this up, you're saying that a negative carryover should be ignored so the next scenario will start with the defined minimum starting gold? Yes, exactly. That is the way it used to be, and also what the dialog says. Do note that during

[Wesnoth-bugs] [bug #20676] gold carryover broken in DiD::Endless Night

Follow-up Comment #3, bug #20676 (project wesnoth): Uh, i just checked again, and I'm apparently wrong about the Normally it works. I did only notice in the scenario mentioned in the title, since it is easy to notice there. Well, then the situation is simpler at least and it's a regular logic

[Wesnoth-bugs] [bug #20676] gold carryover broken in DiD::Endless Night

URL: http://gna.org/bugs/?20676 Summary: gold carryover broken in DiD::Endless Night Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Do 28 Mär 2013 20:13:30 GMT Category: Bug Severity

[Wesnoth-bugs] [bug #20656] [unit] should update fog

URL: http://gna.org/bugs/?20656 Summary: [unit] should update fog Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Di 26 Mär 2013 20:30:55 GMT Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #20656] [unit] should update fog

Update of bug #20656 (project wesnoth): Severity: 3 - Normal = 2 - Minor ___ Reply to this item at: http://gna.org/bugs/?20656 ___ Nachricht

[Wesnoth-bugs] [bug #20656] [unit] should update fog

Update of bug #20656 (project wesnoth): Priority: 5 - Normal = 3 - Low ___ Reply to this item at: http://gna.org/bugs/?20656 ___ Nachricht

[Wesnoth-bugs] [bug #20659] error message when mother unit, child unit and _initial.cfg in same folder

URL: http://gna.org/bugs/?20659 Summary: error message when mother unit, child unit and _initial.cfg in same folder Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Di 26 Mär 2013 23:02:37 GMT

[Wesnoth-bugs] [bug #20659] error message when mother unit, child unit and _initial.cfg in same folder

Follow-up Comment #1, bug #20659 (project wesnoth): The Master of Alchemy is the mother unit/base unit in my previous post, the child unit it tries to base upon that is Aiglathing Level Three in this case, the folder in question is /units/dwarves/

[Wesnoth-bugs] [bug #19624] Random crashes when launching the test scenario

Follow-up Comment #5, bug #19624 (project wesnoth): I can't reproduce it :-( could you ping me on IRC to do an interactive debug session? Are you referring to the valgrind log ? If no, then no, since we already did a long interactive debug session without results (you said you didn't learn much

[Wesnoth-bugs] [bug #20523] crash on loading replay from newer version

Follow-up Comment #2, bug #20523 (project wesnoth): Come on, this isn't a real bug. If one is loading things with a version the loaded thing wasn't created with, one needs to expect all sorts of weird behavior. But most of the time, this tends to work rather well, thus allowing to load things

[Wesnoth-bugs] [bug #19624] Random crashes when launching the test scenario

Follow-up Comment #3, bug #19624 (project wesnoth): I'm posting a portion of the valgrind log, which looks relatively valid and did only show up with the -03 cmake release build, not with an scons debug build, but is over my horizon. This also caused wesnoth to crash (see the assertion failure at

[Wesnoth-bugs] [bug #20418] no one addon work on medium level

Update of bug #20418 (project wesnoth): Status: Need Info = Invalid ___ Reply to this item at: http://gna.org/bugs/?20418 ___ Nachricht

[Wesnoth-bugs] [bug #20418] no one addon work on medium level

Update of bug #20418 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20418 ___ Nachricht

[Wesnoth-bugs] [bug #20418] no one addon work on medium level

Follow-up Comment #2, bug #20418 (project wesnoth): Love to Death is known to be broken. Please try some more and something simple, such as A Simple Campaign. And make sure you have an unmodified wesnoth installation without other addons.

[Wesnoth-bugs] [bug #20374] Python tools should specify Python version

Update of bug #20374 (project wesnoth): Category: Bug = Feature Request Status:None = Fixed ___ Follow-up Comment #2: After talking with

[Wesnoth-bugs] [bug #20374] Python tools should specify Python version

Follow-up Comment #1, bug #20374 (project wesnoth): Of course not limited to unix-like. I suggest adding a note about this to the wiki http://wiki.wesnoth.org/Maintenance_tools I always tried with python 2.x IIRC. ___ Reply to this item

[Wesnoth-bugs] [bug #20360] Wesnoth 1.11.1 crashes on startup

Update of bug #20360 (project wesnoth): Assigned to:None = jamit ___ Follow-up Comment #2: (more info in the forum thread) jamit: Assigning this to you, since it looks as if your changes

[Wesnoth-bugs] [bug #20360] Wesnoth 1.11.1 crashes on startup

Follow-up Comment #3, bug #20360 (project wesnoth): forum thread: http://forums.wesnoth.org/viewtopic.php?f=4t=38017p=544253#p544253 (thought the link is already here sorry) ___ Reply to this item at: http://gna.org/bugs/?20360

[Wesnoth-bugs] [bug #20342] created games sometimes don't show up in mp lobby

Update of bug #20342 (project wesnoth): Status:None = Invalid Assigned to:lipk = None Open/Closed:Open = Closed

[Wesnoth-bugs] [bug #20344] Modifications: none even though it's active and works

Follow-up Comment #2, bug #20344 (project wesnoth): Thanks for spotting the missed closing tag; but I doubt it has to do with the bug. Could you reproduce under any setup ? After some more testing it seems to me that I can reproduce if and only if I connect to the official trunk server, as

[Wesnoth-bugs] [bug #20344] Modifications: none even though it's active and works

Follow-up Comment #3, bug #20344 (project wesnoth): If the remote client has the addon installed as well, it seems the description is shown, otherwise it only shows the id. But I suppose that's intentional. ___ Reply to this item at:

[Wesnoth-bugs] [bug #20342] created games sometimes don't show up in mp lobby

Follow-up Comment #1, bug #20342 (project wesnoth): I tried reproducing on windows and with different hardware without success; this now looks to me as if something on my side is wrong. That Lubuntu system is pretty buggy in general. wesnothd spits out error messages about cannot show game I

[Wesnoth-bugs] [bug #20344] Modifications: none even though it's active and works

URL: http://gna.org/bugs/?20344 Summary: Modifications: none even though it's active and works Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Sun 02 Dec 2012 12:17:50 AM GMT Category: Bug

[Wesnoth-bugs] [bug #20342] created games sometimes don't show up in mp lobby

Follow-up Comment #3, bug #20342 (project wesnoth): Attached wesnothd.txt is the --log-debug=all output from wesnothd. The ERROR: Could not find game for player: anonymissimus is what I was referring to. I started wesnothd independently this time; tried first to create a game which the remote

[Wesnoth-bugs] [bug #20245] Status table scenario settings shows leader id's

Follow-up Comment #2, bug #20245 (project wesnoth): What's shown there actually is the [side]save_id=, which happens to be the leader's id in case it wasn't specified. (So one can put something better there by setting a save_id.) If it changes due to another leader, then that's probably bad and

[Wesnoth-bugs] [bug #20235] mouse right-click in test scenario: iterator out-of-bounds crash

URL: http://gna.org/bugs/?20235 Summary: mouse right-click in test scenario: iterator out-of-bounds crash Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Fr 12 Okt 2012 19:58:13 GMT Category: Bug

[Wesnoth-bugs] [bug #20199] out of bounds access to std::vector in mouse_events.cpp:740

Follow-up Comment #1, bug #20199 (project wesnoth): Using std::vector::at() instead of operator[] makes it crash for me in the MinGw release binary as well, so not a Heisenbug. I still cannot find an exact way to reproduce; try to move around the cursor a bit after moving the wolf rider, select

[Wesnoth-bugs] [bug #20199] out of bounds access to std::map in mouse_events.cpp:740

URL: http://gna.org/bugs/?20199 Summary: out of bounds access to std::map in mouse_events.cpp:740 Project: Battle for Wesnoth Submitted by: anonymissimus Submitted on: Tue 25 Sep 2012 04:44:03 PM GMT Category: Bug

[Wesnoth-bugs] [bug #20199] out of bounds access to std::vector in mouse_events.cpp:740

Update of bug #20199 (project wesnoth): Summary: out of bounds access to std::map in mouse_events.cpp:740 = out of bounds access to std::vector in mouse_events.cpp:740 ___ Reply to this item at:

[Wesnoth-bugs] [bug #20186] [store_unit] / [unstore_unit] bug/absurdity

Follow-up Comment #1, bug #20186 (project wesnoth): wml/lua could get the advancement config of a unit and calculate something from it which has a gamestate-changing effect idependently from unstoring that unit. It doesn't need to be stored/unstored/removed from the map, actually. So your

[Wesnoth-bugs] [bug #20186] [store_unit] / [unstore_unit] bug/absurdity

Update of bug #20186 (project wesnoth): Status:None = Invalid ___ Reply to this item at: http://gna.org/bugs/?20186 ___ Message sent

[Wesnoth-bugs] [bug #20092] Error opening save_index.gz for reading

Update of bug #20092 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20092 ___ Message sent

  1   2   3   4   5   6   7   8   9   10   >