[Wesnoth-bugs] [bug #25467] game map unresponsive

Update of bug #25467 (project wesnoth): Status: Ready For Test => Fixed ___ Follow-up Comment #5: With 1.13.6 it was happening every launch. I haven't yet been able to reproduce the bug with

[Wesnoth-bugs] [bug #16733] timer pause button

Follow-up Comment #2, bug #16733 (project wesnoth): I have a slightly alternative idea, which might serve some of the same needs (but not all), while addressing most of the concerns. At the beginning of the match there could be an agreed upon interval (say, every 45 minutes) after which the

[Wesnoth-bugs] [bug #25467] game map unresponsive

URL: Summary: game map unresponsive Project: Battle for Wesnoth Submitted by: sapient Submitted on: Wed 25 Jan 2017 08:36:09 AM UTC Category: Bug Severity: 5 - Blocker

[Wesnoth-bugs] [bug #24728] typing in lobby's games filter also echoes to chat box

Update of bug #24728 (project wesnoth): Assigned to: sapient => None ___ Reply to this item at: ___ Message

[Wesnoth-bugs] [bug #24481] lobby's games filter input slow and choppy

Update of bug #24481 (project wesnoth): Assigned to: sapient => None ___ Reply to this item at: ___ Message

[Wesnoth-bugs] [bug #24728] typing in lobby's games filter also echoes to chat box

URL: Summary: typing in lobby's games filter also echoes to chat box Project: Battle for Wesnoth Submitted by: sapient Submitted on: Mon 06 Jun 2016 04:16:58 AM UTC Category: Bug

[Wesnoth-bugs] [bug #24481] lobby's games filter input slow and choppy

Update of bug #24481 (project wesnoth): Assigned to:None => sapient ___ Reply to this item at: ___ Message

[Wesnoth-bugs] [bug #16692] Events with name=turn $var don't work

Update of bug #16692 (project wesnoth): Summary: Events with name=turn $var don't work unless quoted = Events with name=turn $var don't work ___ Follow-up Comment #4: Regarding bug #16692, the test code in comment #2

[Wesnoth-bugs] [bug #12871] can't see units' hitpoints in attack dialogs

Update of bug #12871 (project wesnoth): Open/Closed:Open = Closed ___ Follow-up Comment #3: closing since it can no longer be reproduced.

[Wesnoth-bugs] [bug #18701] return 0 for length of arrays inside nonexistent containers

Follow-up Comment #6, bug #18701 (project wesnoth): I can't test at the moment, but that patch ( #14238 ) looks very clean. So if it resolves the test case, then by all means apply it and close this bugreport. Thanks. ___ Reply to this

[Wesnoth-bugs] [bug #16089] variable unit is empty if killed previously in an event

Follow-up Comment #6, bug #16089 (project wesnoth): Technical explanation: The unit at x1,y1 is auto-stored once per event (when first accessed via $-notation or when first utilized for variable storage/modification). Simple explanation: inside an event, this is the unit at $x1,$y1 The

[Wesnoth-bugs] [bug #16089] variable unit is empty if killed previously in an event

Update of bug #16089 (project wesnoth): Category: Bug = Feature Request Assigned to:None = anonymissimus ___ Follow-up Comment #3: This is the way the

[Wesnoth-bugs] [bug #18701] return 0 for length of arrays inside nonexistent containers

URL: http://gna.org/bugs/?18701 Summary: return 0 for length of arrays inside nonexistent containers Project: Battle for Wesnoth Submitted by: sapient Submitted on: Tue 20 Sep 2011 02:34:43 PM GMT Category: Bug

[Wesnoth-bugs] [bug #18691] GUI glitch with long add-on author field

URL: http://gna.org/bugs/?18691 Summary: GUI glitch with long add-on author field Project: Battle for Wesnoth Submitted by: sapient Submitted on: Mon 19 Sep 2011 10:15:42 AM GMT Category: Bug Severity: 3

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

Follow-up Comment #2, bug #18693 (project wesnoth): For what it's work, I think this is a bad idea. 1. Majority of players do not know how to modify and recompile the source or are using a platform where it requires extra effort (i.e. Windows) 2. Although some cheat because they think they are

[Wesnoth-bugs] [bug #18284] [objectives] dialog with note=very long text doesn't work well

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

[Wesnoth-bugs] [bug #16692] name=turn $var - event's don't work

Update of bug #16692 (project wesnoth): Status:Wont Fix = Confirmed ___ Follow-up Comment #2: How is this won't fix? I consider this a valid bug. The following code worked in 1.6 but no

[Wesnoth-bugs] [bug #16692] name=turn $var - event's don't work

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

[Wesnoth-bugs] [bug #16344] In Cliffs of Thoria the location_filter does not work correctly on drake bases

Follow-up Comment #4, bug #16344 (project wesnoth): Thanks for spotting that, but actually the bug was introduced in r41953 http://svn.gna.org/viewcvs/wesnoth/?rev=41953view=rev. ___ Reply to this item at: http://gna.org/bugs/?16344

[Wesnoth-bugs] [bug #13961] property inheritance

Update of bug #13961 (project wesnoth): Status:None = Wont Fix ___ Follow-up Comment #2: this would involve changes that are too extensive for benefits that are questionable at best.

[Wesnoth-bugs] [bug #14550] needs_select for menu item does not work after moving selected unit

URL: http://gna.org/bugs/?14550 Summary: needs_select for menu item does not work after moving selected unit Project: Battle for Wesnoth Submitted by: sapient Submitted on: Sunday 10/18/2009 at 03:46 Category: Bug

[Wesnoth-bugs] [bug #14550] needs_select for menu item does not work after moving selected unit

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

[Wesnoth-bugs] [bug #13734] phantom containers in auto-stored unit variables

Update of bug #13734 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #5: I submitted a fix but my computer is too slow to build and test it in a reasonable timeframe.

[Wesnoth-bugs] [bug #13365] [primary_unit] improvements

URL: http://gna.org/bugs/?13365 Summary: [primary_unit] improvements Project: Battle for Wesnoth Submitted by: sapient Submitted on: Monday 04/13/2009 at 04:39 Category: Feature Request Severity: 2 -

[Wesnoth-bugs] [patch #1148] random village naming: second sylabus

Follow-up Comment #9, patch #1148 (project wesnoth): While this patch should work, it would be better to avoid a hard-coded t_list of terrains as follows: 1. create a t_translation::t_match which will match all forests (do this outside the main loop if possible to avoid re-creating it each

[Wesnoth-bugs] [bug #13274] altered [advancement]s don't take effect

Update of bug #13274 (project wesnoth): Category: Bug = Feature Request ___ Follow-up Comment #3: I am really surprised that this worked in 1.5.13 because I cannot find any support in the code

[Wesnoth-bugs] [bug #13193] Weapon special filter should use id instead of tag name

Update of bug #13193 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #2: Note: to avoid breaking existing code, weapon special filtering will now match when either the

[Wesnoth-bugs] [bug #13024] Conditional [allow_undo] doesn't always work right

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

[Wesnoth-bugs] [bug #13024] Conditional [allow_undo] doesn't always work right

Update of bug #13024 (project wesnoth): Status: Confirmed = Fixed ___ Follow-up Comment #3: This bug went all the way back to May/June of last year when suokko made some major changes to

[Wesnoth-bugs] [bug #11359] OOS when using [unstore_unit] + experience modifications

Follow-up Comment #3, bug #11359 (project wesnoth): The handling of max_experience modification has greatly changed between 1.4 and 1.5, so I'm not sure if this one is still valid. I can't test anything that requires running two clients, unless maybe someone volunteers to assist me. However,

[Wesnoth-bugs] [patch #1122] patch for scons - allow rename target instead of hardlink

URL: http://gna.org/patch/?1122 Summary: patch for scons - allow rename target instead of hardlink Project: Battle for Wesnoth Submitted by: sapient Submitted on: Thursday 02/12/2009 at 22:40 Priority: 4

[Wesnoth-bugs] [bug #12963] Floating-point exception in sample.py vs. sample.py

Update of bug #12963 (project wesnoth): Item Group:Graphics = Artificial Intelligence ___ Reply to this item at: http://gna.org/bugs/?12963 ___ Message sent

[Wesnoth-bugs] [bug #12963] Floating-point exception in sample.py vs. sample.py

Update of bug #12963 (project wesnoth): Severity: 5 - Blocker = 2 - Minor Status: Need Info = Ready For Test ___ Reply to this item at:

[Wesnoth-bugs] [bug #12959] dismissal with Esc causes WML menu items to never appear again

URL: http://gna.org/bugs/?12959 Summary: dismissal with Esc causes WML menu items to never appear again Project: Battle for Wesnoth Submitted by: sapient Submitted on: Monday 02/09/2009 at 02:23 Category: Bug

[Wesnoth-bugs] [bug #12946] [menu_item]/[command] losing function when called again

Update of bug #12946 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #2: this was a really bad bug, thanks for reporting it! :)

[Wesnoth-bugs] [bug #12929] WML: Order of action in fired event in game should be the same as that in wml

Update of bug #12929 (project wesnoth): Status:None = Works For Me ___ Follow-up Comment #3: Works for me. See the attached scenario-test.cfg file. Replace your scenario-test.cfg with

[Wesnoth-bugs] [bug #12946] [menu_item]/[command] losing function when called again

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

[Wesnoth-bugs] [bug #12929] WML: Order of action in fired event in game should be the same as that in wml

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

[Wesnoth-bugs] [bug #12929] WML: Order of action in fired event in game should be the same as that in wml

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

[Wesnoth-bugs] [bug #12929] WML: Order of action in fired event in game should be the same as that in wml

Update of bug #12929 (project wesnoth): Category: Feature Request = Bug Severity:1 - Wish = 3 - Normal Status:None = Need Info

[Wesnoth-bugs] [bug #12898] The maximum text width is less than 1.

Update of bug #12898 (project wesnoth): Status: Need Info = In Progress Assigned to: sapient = mordante ___ Follow-up Comment #4: This bugfix has

[Wesnoth-bugs] [bug #12898] The maximum text width is less than 1.

Update of bug #12898 (project wesnoth): Status:None = Need Info ___ Follow-up Comment #2: your attached savefile is messed up. please rename it something simpler, without the '-symbol,

[Wesnoth-bugs] [bug #12924] Invalid AI recruit list crashes campaigns back to main menu

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

[Wesnoth-bugs] [bug #12894] [recall] causes crash

Update of bug #12894 (project wesnoth): Status:None = Fixed Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #12897] wmllint / wmliterator.py confused by commented preprocessor directives

Update of bug #12897 (project wesnoth): Item Group: None of the others = WML Status:None = Invalid Assigned to:None = sapient

[Wesnoth-bugs] [bug #12897] wmllint / wmliterator.py confused by commented preprocessor directives

Follow-up Comment #2, bug #12897 (project wesnoth): Furthermore, I would like to point out that WmlIterator.py has a feature to silence any duplicate warning messages, but ESR deliberately decided to override my implementation with his own version (in wmllint).

[Wesnoth-bugs] [bug #12885] Second unit not always selected on sighted event

Update of bug #12885 (project wesnoth): Status:None = Wont Fix ___ Follow-up Comment #1: This is due the way the sighted event works. It has always been buggy. The sighted event is

[Wesnoth-bugs] [bug #12871] can't see units' hitpoints in attack dialogs

URL: http://gna.org/bugs/?12871 Summary: can't see units' hitpoints in attack dialogs Project: Battle for Wesnoth Submitted by: sapient Submitted on: Saturday 01/17/2009 at 18:37 Category: Bug Severity: 3

[Wesnoth-bugs] [bug #12864] Random bugs, apparently with WML events spawned by other events

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

[Wesnoth-bugs] [bug #12824] Random bug with WML variables

Update of bug #12824 (project wesnoth): Item Group: None of the others = WML Status: Need Info = Fixed ___ Follow-up Comment #7: Patterner ran

[Wesnoth-bugs] [bug #12824] Random bug with WML variables

Update of bug #12824 (project wesnoth): Status:None = Need Info ___ Follow-up Comment #4: Thanks for your help tracking down this bug. However, the Save Game you posted is not a valid

[Wesnoth-bugs] [bug #12546] WML variables not completely compatible with standard mathematical operations

Update of bug #12546 (project wesnoth): Assigned to: sapient = ai0867 ___ Follow-up Comment #2: AI0867 has already indicated that he would like to work on this, so I am assigning it to him.

[Wesnoth-bugs] [bug #12558] Units no longer assigned unique id's

Update of bug #12558 (project wesnoth): Status:None = Fixed Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #12375] 2 new events: consider attack + unconsider attack

Follow-up Comment #8, bug #12375 (project wesnoth): Ken -- my mind may be playing tricks on me and I have a notoriously bad memory, but I seem to remember discussing it in irc or in-game. ActionWML is overkill for this situation because it can have so many side effects, including killing or

[Wesnoth-bugs] [bug #10337] AMLA special abilities don't show up in help before they're applied

Update of bug #10337 (project wesnoth): Status: In Progress = Fixed ___ Reply to this item at: http://gna.org/bugs/?10337 ___ Message sent

[Wesnoth-bugs] [bug #12375] 2 new events: consider attack + unconsider attack

Update of bug #12375 (project wesnoth): Status: Ready For Test = Wont Fix ___ Follow-up Comment #5: Ken, we have already discussed this and you should not submit a feature request for idea

[Wesnoth-bugs] [bug #12470] Fog always revealed on moveto events

Update of bug #12470 (project wesnoth): Status:None = Invalid Assigned to:None = sapient ___ Follow-up Comment #1: I could not

[Wesnoth-bugs] [bug #10337] AMLA special abilities don't show up in help before they're applied

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

[Wesnoth-bugs] [bug #10130] Make alterations to units and sides direct

Update of bug #10130 (project wesnoth): Assigned to:None = sapient ___ Follow-up Comment #2: if I understand this bug correctly, it was something I already fixed for WesBand

[Wesnoth-bugs] [bug #12252] The Oldwood the Rise of wesnoth crash

Update of bug #12252 (project wesnoth): Item Group:Campaign = Artificial Intelligence ___ Reply to this item at: http://gna.org/bugs/?12252 ___ Message sent

[Wesnoth-bugs] [patch #1090] Mostly separate user_team_name from team_name

Follow-up Comment #1, patch #1090 (project wesnoth): This patch removes most of that; In the status table, if there's no user_team_name, it'll now display the string Team {X}, where {X} is the side number of the first side on that team. (Yes, in a 2vs2, you could end up with Team 1 vs.

[Wesnoth-bugs] [bug #12180] Make wmlindent a little smarter

Follow-up Comment #1, bug #12180 (project wesnoth): For what it's worth, I agree that the wmlindent indentation style needs to get this upgrade. The easy way is to have a hard-coded list of unbalanced macro pairs i.e. FOREACH/NEXT. The most versatile way would be to build a list of such

[Wesnoth-bugs] [bug #11842] Animations getting mixed up on advancement

Follow-up Comment #3, bug #11842 (project wesnoth): Sapient 14:52 Elvish_Pillage2 jeez, I've got a Wraith that looks exactly like a Ghost except when it's attacking. I wonder how that happened... Sapient sounds like a bug in unit::advance_to() Sapient some tags are not getting cleared Sapient so

[Wesnoth-bugs] [bug #12091] wmllint can't handle empty attributes

Update of bug #12091 (project wesnoth): Status:None = Need Info ___ Follow-up Comment #1: I just tried to duplicate this error with no luck. The script did not crash when I supplid an

[Wesnoth-bugs] [bug #12106] serialization of attacks loses most [effect] modifications

Update of bug #12106 (project wesnoth): Item Group:None = None of the others Status:None = Fixed Assigned to:None = sapient

[Wesnoth-bugs] [patch #1085] Adding TRANSFORM_UNIT macro.

Update of patch #1085 (project wesnoth): Status:None = Done Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #12094] Event last breath cannot be triggered for attackers

Update of bug #12094 (project wesnoth): Status:None = Ready For Test Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #11988] Events with multiple types are multiplied

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

[Wesnoth-bugs] [bug #11988] Events with multiple types are multiplied

Follow-up Comment #6, bug #11988 (project wesnoth): This fix is most definitely *not* correct and could have unintended side-effects. I am reverting it. ___ Reply to this item at: http://gna.org/bugs/?11988

[Wesnoth-bugs] [bug #12019] [store_unit] or [unstore_unit] resets attacks_left to 1.

Update of bug #12019 (project wesnoth): Severity: 5 - Blocker = 3 - Normal Priority: 9 - Immediate = 3 - Low ___ Follow-up Comment #4: ok, changing the

[Wesnoth-bugs] [bug #12019] [store_unit] or [unstore_unit] resets attacks_left to 1.

Update of bug #12019 (project wesnoth): Severity: 3 - Normal = 5 - Blocker ___ Follow-up Comment #1: I consider bug #12019 (un-confirmed) to be a 1.4 blocker I don't have a 1.4 checkout setup,

[Wesnoth-bugs] [bug #12019] [store_unit] or [unstore_unit] resets attacks_left to 1.

Update of bug #12019 (project wesnoth): Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://gna.org/bugs/?12019 ___ Message sent

[Wesnoth-bugs] [bug #11980] Garbled output with [set_variables] starting with a specific array container

Update of bug #11980 (project wesnoth): Status:None = Fixed Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #11981] Inability to use set_variables/to_variable to insert only 1 part of an array

Update of bug #11981 (project wesnoth): Status:None = Fixed Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #11239] Roles assigned to units are not preserved when moving to next scenario.

Update of bug #11239 (project wesnoth): Status: Confirmed = Fixed Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #4124] roles not preserved across scenarios

Update of bug #4124 (project wesnoth): Status: Duplicate = Fixed Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #11947] Halo is kept over advancement.

Update of bug #11947 (project wesnoth): Assigned to: sapient = boucman ___ Follow-up Comment #3: It should be a simple matter of clearing the halo in unit::advance_to(), right next to the part

[Wesnoth-bugs] [bug #11424] Attacks cannot be modified directly

Update of bug #11424 (project wesnoth): Status:None = In Progress Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [bug #11813] Gender-specific unit advancements cause segmentation fault

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

[Wesnoth-bugs] [bug #11813] Gender-specific unit advancements cause segmentation fault

Follow-up Comment #2, bug #11813 (project wesnoth): Sapient look at this Sapient unit_type_map::iterator itor_advanceto = types_.find(*i_adv); Sapient itor_advanceto-second.add_advancesfrom(unit_cfg[id]); Sapient now why didn't it check to see if the type was found or

[Wesnoth-bugs] [bug #11779] Bug with filter + delete savegame

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

[Wesnoth-bugs] [bug #11654] Stange situation with teleport feature

Update of bug #11654 (project wesnoth): Status:None = Duplicate Assigned to: sapient = noyga ___ Follow-up Comment #2: duplicate of bug

[Wesnoth-bugs] [bug #11207] Infinite recursion with [kill]fire_event=yes on die event

Update of bug #11207 (project wesnoth): Severity: 4 - Important = 2 - Minor ___ Follow-up Comment #2: This feature has *always* allowed infinite recursion if it was used improperly, and it was up

[Wesnoth-bugs] [patch #1046] unit map improvements

Follow-up Comment #5, patch #1046 (project wesnoth): Hey, I requested three different types of 'accessors', I was all fine with one type of iterator. ;) But an iterator is basically the same thing with additional feature++. And yes, it was needed. Now it just needs to be used / advertised.

[Wesnoth-bugs] [patch #1032] [endlevel][result] tag to allow different scenario results for different sides

Follow-up Comment #5, patch #1032 (project wesnoth): I disagree with firing both victory and defeat... if the client is controlling both a victorious and defeated side, then the side that is currently active should take precedence for determining which one to fire. Attempting to fire both could

[Wesnoth-bugs] [patch #1037] Filter_x renaming

Update of patch #1037 (project wesnoth): Status: In Progress = Done ___ Reply to this item at: http://gna.org/patch/?1037 ___ Message sent

[Wesnoth-bugs] [task #5882] Clean up filter tags

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

[Wesnoth-bugs] [patch #1037] Filter_x renaming

Update of patch #1037 (project wesnoth): Status: Ready For Test = In Progress ___ Reply to this item at: http://gna.org/patch/?1037 ___ Message sent

[Wesnoth-bugs] [patch #1045] is_set variable condition

Follow-up Comment #9, patch #1045 (project wesnoth): It sounds like the person who worked on the Tutorial had a bug in their code and was simply confused. This method of testing for empty string works fine: [variable] name=foo equals=$empty [/variable] This method had problems in the past

[Wesnoth-bugs] [patch #1045] is_set variable condition

Follow-up Comment #3, patch #1045 (project wesnoth): I really don't see the need for this. All unset variables in WML are string equivalent to empty string, numerically equivalent to zero, and boolean equivalent to false. Making a distinction between set and unset doesn't grant any real

[Wesnoth-bugs] [patch #1045] is_set variable condition

Follow-up Comment #4, patch #1045 (project wesnoth): Another point to consider: since arrays and scalars do not share the same namespace, I could have a container named foo and yet is_set for foo would return false. This ambiguity is another reason I am against introducing this feature.

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Update of patch #1020 (project wesnoth): Status:None = In Progress ___ Follow-up Comment #16: I'm basically approving patch 1020, although I don't have a means to extensively check it

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Update of patch #1020 (project wesnoth): Status: In Progress = Done Assigned to:None = sapient ___ Reply to this item at:

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #14, patch #1020 (project wesnoth): 1) Your invalidation method goes a step further than revision_number and allows changes to (other) parts of the unitmap without re-perform the find operation. So I guess it does have some advantage. Still, I would be comforted to know that at

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #6, patch #1020 (project wesnoth): I am glad to see someone tackle this idea finally. Unfortunately, you missed the most important part of the proposal: throwing a unit_map_iterator_invalid exception when someone tries to access an invalid unit iterator. Another big

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #7, patch #1020 (project wesnoth): slight correction to comment below: refresh would be a successful find_pair with new revision number. ___ Reply to this item at: http://gna.org/patch/?1020

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #12, patch #1020 (project wesnoth): regarding #1, it may break some things but that is the point. the places where it 'breaks' should be switched to using the new style of iterators. it's a development version so that's OK. that's also why this is on the NotSoEasy coding page

[Wesnoth-bugs] [patch #934] split and join for set_variable

Update of patch #934 (project wesnoth): Assigned to: sapient = cib ___ Reply to this item at: http://gna.org/patch/?934 ___ Message sent

[Wesnoth-bugs] [bug #11187] [music] play_once=yes doesn't work in defeat events

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

[Wesnoth-bugs] [bug #11027] never connects to remote host(s)

URL: http://gna.org/bugs/?11027 Summary: never connects to remote host(s) Project: Battle for Wesnoth Submitted by: sapient Submitted on: Sunday 02/10/08 at 11:44 Category: Bug Severity: 4 - Important

  1   2   >