URL:
http://gna.org/bugs/?19322
Summary: controller=null hides a side
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Mon 23 Jan 2012 02:41:19 PM EST
Category: Bug
Severity: 3 - Normal
Follow-up Comment #3, bug #19319 (project wesnoth):
On a US-English keyboard, hitting the plus sign does not require hitting the
shift key if you use the numeric keypad. (And since there is no equals sign on
my numeric keypad, this change could be inconvenient for those who use the
numeric
URL:
http://gna.org/bugs/?19324
Summary: Units can unstore with non-positive hit points
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Mon 23 Jan 2012 03:17:07 PM EST
Category: Bug
URL:
http://gna.org/bugs/?19334
Summary: ON_SIGHTING macro too often blocking undo
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Fri 27 Jan 2012 12:22:42 AM EST
Category: Bug
Severity: 2 -
Follow-up Comment #8, bug #17244 (project wesnoth):
Is this possibly a duplicate of bug #17868? (Well, given the original
submission dates, I suppose that one would have to be considered a duplicate
of this.)
Anyway, when I've encountered this, I have not needed to press multiple keys
or spam a
URL:
http://gna.org/patch/?3120
Summary: Redundant if in clear_shroud_loc()
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Sat 04 Feb 2012 12:59:22 PM EST
Priority: 3 - Low
Status: None
URL:
http://gna.org/patch/?3122
Summary: Simpler pathfinding
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Sun 05 Feb 2012 03:57:14 PM EST
Priority: 5 - Normal
Status: None
Follow-up Comment #1, bug #19419 (project wesnoth):
I would soften the ONLY part. For example, if the friendly unit can one-hit
kill with a ranged attack, it may be worth considering. Or if the ranged
attack is magical, especially against elusive foots.
Possibly it would be enough for the AI to
URL:
http://gna.org/patch/?3133
Summary: Movement algorithm
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Wed 15 Feb 2012 07:16:42 PM EST
Priority: 5 - Normal
Status: None
Additional Item Attachment, patch #3133 (project wesnoth):
File name: wesnoth-move-bug-1-crop.pngSize:903 KB
___
Reply to this item at:
http://gna.org/patch/?3133
___
Message sent
Additional Item Attachment, patch #3133 (project wesnoth):
File name: wesnoth-move-bug-2-crop.pngSize:901 KB
___
Reply to this item at:
http://gna.org/patch/?3133
___
Message sent
Follow-up Comment #2, patch #3133 (project wesnoth):
Smaller functions? I could do that. (In fact, I would prefer that. It just
seemed as though the existing style had a preference for monolithic functions,
so I went with what was there.)
Yes, same name from the forums.
Yes, this is dangerous
Follow-up Comment #3, patch #3133 (project wesnoth):
OK, I divided the function into more manageable pieces, and the patch into two
parts. The first part is just splitting the current function into its parts,
while the second also converts those parts to my new algorithm.
(file #15164, file
Follow-up Comment #5, patch #3133 (project wesnoth):
I hope it's apparent, but I'll say it anyway: I did not get that error when I
compiled it (gcc 4.4.3, Ubuntu 10.04). The relevance of which is that I cannot
be sure that any particular change will eliminate that error.
However, I do have a
Additional Item Attachment, patch #3133 (project wesnoth):
File name: movement-split.diffSize:24 KB
___
Reply to this item at:
http://gna.org/patch/?3133
___
Message sent
Follow-up Comment #2, bug #19324 (project wesnoth):
OK, that's a strange usecase, but at least it has a use. Maybe that's why the
documentation does not mention the zero-hitpoint case. (Although maybe it
should, for completeness if nothing else.) The negative hit points still look
odd when
Follow-up Comment #4, bug #19324 (project wesnoth):
Modifying a unit in the last_breath event -- I like it! :) You have convinced
me that the documentation was the better thing to change.
___
Reply to this item at:
URL:
http://gna.org/patch/?3176
Summary: Ghost images for units covered by fog
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Thu 01 Mar 2012 03:09:46 PM EST
Priority: 5 - Normal
Status:
URL:
http://gna.org/bugs/?19519
Summary: UtBS doubled Black Hand dialog
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Fri 02 Mar 2012 02:54:32 AM EST
Category: Bug
Severity: 2 - Minor
Follow-up Comment #1, bug #19503 (project wesnoth):
After seeing my autosave list grow to over 200 saves long, I decided to do a
little digging...
At line 466 in savegame.cpp (inside the remove_old_auto_saves() function),
there is a call to get_saves_list(), a function that takes up to two
Follow-up Comment #2, bug #19503 (project wesnoth):
Played a bit more, trying out what I just posted, and most of my saves
(including end-of-scenario saves) have been deleted. So there is something
else going on, but at least it might be a place to start looking.
Follow-up Comment #3, bug #19503 (project wesnoth):
Think I found the something else. Same file, this time inside the
get_saves_list() function. At lines 274-275, there is a call to
filenames.erase() with only one parameter, which causes only a single entry to
be erased, when the apparent intent
Follow-up Comment #2, patch #3176 (project wesnoth):
Really? Guess I am surprised given at how intentional the coding to implement
fogging-within-a-turn appears. (I had assumed it was so that WML could change
things out of a players sight, but with Zookeeper behind this change, I guess
not.)
Follow-up Comment #4, patch #3176 (project wesnoth):
Touche! It is true that developing a program can be a process of evolution.
:)
I see something of an issue with the tags as described. To refog what is not
directly visible would be inconsistent with the whole should never be
covered again
Additional Item Attachment, patch #3176 (project wesnoth):
File name: shroud-toggle.diff Size:0 KB
___
Reply to this item at:
http://gna.org/patch/?3176
___
Message sent via/by
Follow-up Comment #9, patch #3176 (project wesnoth):
Boucman: does this clarify things?
Suppose side 1 uses fog and there is something happening at hex 10,12 that
side 1 should see. The current way to do this is with {CLEAR_FOG 1 10 12 4}
(or whatever radius is appropriate), followed by
Follow-up Comment #10, patch #3176 (project wesnoth):
Anonymissimus:
The numbered patches (0- through 4-) are the original submission. This is
currently being considered as superceded by the alternative submission; I
would flag them as such, but I do not see a way to mark files as no longer
Follow-up Comment #5, bug #16148 (project wesnoth):
I believe I have been able to reproduce this crash in a simpler case by
putting a [recall] within a die or last_breath event, and having that
event result from combat. I've attached a short scenario demonstrating this.
(Just kill the walking
Follow-up Comment #16, patch #3176 (project wesnoth):
I've updated the wiki.
I can do the new tag, but it might be a few days. (Just bad timing with real
life.)
___
Reply to this item at:
http://gna.org/patch/?3176
URL:
http://gna.org/bugs/?19557
Summary: TRANSFORM_UNIT needs a variable renamed
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Sat 17 Mar 2012 10:59:32 AM EDT
Category: Bug
Severity: 3 -
URL:
http://gna.org/patch/?3195
Summary: Remove #define MAX_MAP_AREA
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Tue 20 Mar 2012 06:41:35 PM EDT
Priority: 5 - Normal
Status: None
URL:
http://gna.org/patch/?3196
Summary: Showing all units in replays
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Tue 20 Mar 2012 07:48:00 PM EDT
Priority: 5 - Normal
Status: None
URL:
http://gna.org/patch/?3197
Summary: reapply_fog
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Tue 20 Mar 2012 08:54:28 PM EDT
Priority: 5 - Normal
Status: None
Follow-up Comment #8, patch #3133 (project wesnoth):
brilliand:
I thought about adding a movethrough event myself, but decided to fix the
algorithm before adding complexities to it. On the other hand, if adding
complexities fixes the algorithm as a side-effect, that might be a more
efficient
Additional Item Attachment, patch #3197 (project wesnoth):
File name: reset_view-changelog.diff Size:0 KB
___
Reply to this item at:
http://gna.org/patch/?3197
___
Message sent via/by
URL:
http://gna.org/patch/?3200
Summary: Saving fog
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Fri 23 Mar 2012 01:08:21 PM EDT
Priority: 5 - Normal
Status: None
Follow-up Comment #1, patch #3186 (project wesnoth):
I said elsewhere that I would check this patch against the issues that patch
#3133 addresses. In the process, I came up with what may be a nice little test
scenario for this patch.
For the nominal purpose of comparing this to my patch, all one
Follow-up Comment #12, patch #3186 (project wesnoth):
brilliand:
Well, no, there are no other events that would interrupt movement, but then
again there are currently no events that trigger in the middle of movement. (I
did say similar, not same.) However, sighting a unit can interrupt
movement
Follow-up Comment #11, patch #3133 (project wesnoth):
Well, I had figured the team::seen_ stuff had to do with something I read a
while ago dealing with music and multiplayer. My main concern was to keep it
working at least as well as it had been previously, and I could look at it
more later.
Follow-up Comment #14, patch #3186 (project wesnoth):
Both enter_hex and exit_hex? I could see that working. Would enter_hex get the
previous hex as its secondary location?
___
Reply to this item at:
http://gna.org/patch/?3186
Follow-up Comment #17, patch #3186 (project wesnoth):
I think you are taking the view that enter/exit hex events would behave
similarly to unit sightings in that they would not interrupt movement after
pressing 't'? I think that would be a wrong approach to take; event
interruptions should have
Follow-up Comment #19, patch #3186 (project wesnoth):
Are you significantly increasing the complexity of the code in order to stay
true to your one possible use? (A use that I would expect to be uncommon to
rare, but I could not speak for most people anticipating this event.) Maybe it
is worth
Follow-up Comment #20, patch #3186 (project wesnoth):
Well, I guess I messed up the markup somehow, and the WML is not getting
displayed. I tried:
# Do not interrupt movement now.
[allow_undo]
[/allow_undo]
# Clear the undo stack when this move is finished.
[event]
Update of bug #19393 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #2:
Fixed in trunk.
(Probably fixed by https://gna.org/patch/?3196)
Update of bug #19381 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Reply to this item at:
Update of patch #3133 (project wesnoth):
Status:None = Done
___
Reply to this item at:
http://gna.org/patch/?3133
___
Message sent
Update of bug #19628 (project wesnoth):
Status:None = Confirmed
___
Follow-up Comment #3:
I am going to consider this revealed by r53751, rather than caused by it.
(There is a @todo
URL:
http://gna.org/bugs/?19630
Summary: Lost a unit in UtBS S8
Project: Battle for Wesnoth
Submitted by: jamit
Submitted on: Mon 09 Apr 2012 12:37:12 AM EDT
Category: Bug
Severity: 3 - Normal
Update of bug #19628 (project wesnoth):
Status: Confirmed = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19628
___
Message sent
Update of bug #19632 (project wesnoth):
Assigned to:None = gabba
___
Follow-up Comment #2:
The crash appears to be a consequence of the changes to game_display.cpp
introduced by r53781.
Follow-up Comment #21, patch #3186 (project wesnoth):
I have some more modifications (in addition to (the completed) patch #3133)
planned for move_unit() (basically streamlining/simplifying some stuff). Would
you want a chance to get this patch finalized before that function changes
again? (Did
Follow-up Comment #4, bug #19393 (project wesnoth):
Yes. Revision 53814, so the fix should be in 1.10.2.
___
Reply to this item at:
http://gna.org/bugs/?19393
___
Message sent via/by Gna!
Update of bug #19393 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19393
___
Message sent
Update of bug #19628 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19628
___
Message sent
Follow-up Comment #1, bug #19663 (project wesnoth):
*Summary of the info that can be seen in the replay:*
A wose (not the ancient or elder versions) has two death animations. If it is
killed by blade, impact, or pierce, then it falls over, uprooted. If it is
killed by arcane, fire, or cold, then
Update of bug #19713 (project wesnoth):
Status:None = Invalid
___
Follow-up Comment #1:
Not a bug. Your units all have hide_help=true in them, which causes them to
be hidden in the
Update of bug #19723 (project wesnoth):
Assigned to:None = nephro
___
Reply to this item at:
http://gna.org/bugs/?19723
___
Message sent
Follow-up Comment #1, bug #19623 (project wesnoth):
The word is that inspecting shroud data had caused crashes in some cases
(particularly for large maps and small screens). It looks like the crash is
gone in 1.11, so this should be OK to implement. If I can confirm no crash in
1.10, I think this
Update of bug #19623 (project wesnoth):
Status:None = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19623
___
Message sent
Follow-up Comment #1, bug #19734 (project wesnoth):
Intended behavior: the first unit completing its move is required before other
orders can be issued.
Are you saying that there were times when the second unit's movement order was
*accepted* before the first unit finished moving? That would be
Update of bug #19734 (project wesnoth):
Status:None = Confirmed
Assigned to:None = jamit
___
Follow-up Comment #3:
There does seem to
Follow-up Comment #2, bug #19758 (project wesnoth):
I think r54350 does not address the bug reported here. That revision adds more
triggers for the event where the player chooses elves or bandits, yet the bug
report here states that the choice was already made. (I'm not sure the extra
triggers
Update of bug #19734 (project wesnoth):
Status: Confirmed = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19734
___
Message sent
Update of bug #19788 (project wesnoth):
Status:None = Confirmed
Assigned to:None = jamit
___
Reply to this item at:
Update of bug #19788 (project wesnoth):
Status: Confirmed = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #19855 (project wesnoth):
Assigned to:None = jamit
___
Follow-up Comment #1:
I can see suppressing those messages when the animations are suppressed, but
why should the
Update of bug #19856 (project wesnoth):
Assigned to:None = jamit
___
Reply to this item at:
http://gna.org/bugs/?19856
___
Message sent
Update of bug #19856 (project wesnoth):
Status:None = Confirmed
___
Reply to this item at:
http://gna.org/bugs/?19856
___
Message sent
Update of bug #19844 (project wesnoth):
Status:None = Confirmed
Assigned to:None = jamit
___
Reply to this item at:
Update of bug #19280 (project wesnoth):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Let's look at what
Follow-up Comment #1, bug #19533 (project wesnoth):
Some additional info:
First (what you can see if you download the attached image), this bug concerns
the tooltip for the lines like melee-impact in the side bar. It does not
affect the tooltip for lines like 19-2 crush, nor does it affect the
Update of bug #19856 (project wesnoth):
Status: Confirmed = In Progress
___
Follow-up Comment #2:
Sorry, the bug caused those saves to have bad data in them. They still will
not replay properly,
Update of bug #19795 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Reply to this item at:
Follow-up Comment #1, bug #19877 (project wesnoth):
While the symptom is this crash, the problem began earlier. For some reason
the replay is missing some key data -- map and side info, at least. (The lack
of side info is what leads to this crash when attempting to watch a replay.)
Follow-up Comment #3, bug #19861 (project wesnoth):
Your question assumes that the host has the option to disable undos, which is
not the case as far as I know. The game (not the host, but _Battle for
Wesnoth_ itself) is the one that allows moves to be undone. It is rather
trivial to edit a
Update of bug #19744 (project wesnoth):
Status:None = Fixed
Assigned to: gabba = jamit
___
Follow-up Comment #3:
I did not see the
Update of bug #19751 (project wesnoth):
Status:None = Works For Me
___
Follow-up Comment #2:
I thought I would take a shot at confirming this, and I was unable to
reproduce the bug. The
Follow-up Comment #1, bug #19620 (project wesnoth):
Is this still an issue? I thought the press T message was suppressed when
executing whiteboard moves since r52055.
___
Reply to this item at:
http://gna.org/bugs/?19620
Follow-up Comment #8, bug #19861 (project wesnoth):
For example, the following WML makes it impossible to undo anything except
dismissals from the recall list:
[event]
name=moveto,recruit,recall
first_time_only=no
[/event]
This event could be added to either a scenario or an era to
Update of bug #17948 (project wesnoth):
Status:None = Fixed
Assigned to:crab = jamit
___
Follow-up Comment #3:
This got fixed in
Update of bug #14269 (project wesnoth):
Assigned to:crab = jamit
___
Follow-up Comment #5:
There is hope sighted events will be fixed in 1.11.
Follow-up Comment #2, bug #20051 (project wesnoth):
Also, default loyalists are missing the bowman, lieutenant, and spearman.
Interestingly, all of these missing units advance from a unit that is not in
the multiplayer factions (woodsman, peasant, sergeant, ruffian, and young
ogre).
Follow-up Comment #1, bug #19978 (project wesnoth):
Forum discussion: http://forum.wesnoth.org/viewtopic.php?f=21t=37274
___
Reply to this item at:
http://gna.org/bugs/?19978
___
Message
Update of bug #19783 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Reply to this item at:
Update of bug #20036 (project wesnoth):
Severity: 3 - Normal = 2 - Minor
Status:None = Confirmed
___
Follow-up Comment #1:
I did a quick check
Update of bug #20048 (project wesnoth):
Status:None = Invalid
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #19978 (project wesnoth):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Reported in the
Update of bug #19533 (project wesnoth):
Item Group: Units = User Interface
Status:None = Fixed
Assigned to:None = jamit
Update of bug #19844 (project wesnoth):
Status: Confirmed = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19844
___
Message sent
Update of patch #3133 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/patch/?3133
___
Message sent
Update of bug #19343 (project wesnoth):
Assigned to:None = jamit
Release: 1.1.10+svn (52780) = 1.10.0+svn (52780)
___
Follow-up Comment #1:
I think this got
Update of bug #16711 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Reply to this item at:
Update of bug #13178 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Follow-up Comment #2:
Per-scenario
Update of bug #3836 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Follow-up Comment #7:
Per-scenario
Update of bug #20160 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Follow-up Comment #1:
I do not see this
Update of bug #20166 (project wesnoth):
Severity: 3 - Normal = 1 - Wish
Release:2.10 = 1.10
___
Follow-up Comment #1:
For the I forget
Follow-up Comment #2, patch #3525 (project wesnoth):
Right, accessing a vector iterator after erasing it is bad.
___
Reply to this item at:
http://gna.org/patch/?3525
___
Message sent
Update of patch #3525 (project wesnoth):
Status:None = Done
Assigned to:None = jamit
___
Reply to this item at:
Update of bug #19250 (project wesnoth):
Status:None = Fixed
Assigned to:None = jamit
___
Reply to this item at:
Update of bug #20118 (project wesnoth):
Assigned to:None = jamit
___
Reply to this item at:
http://gna.org/bugs/?20118
___
Message sent
1 - 100 of 296 matches
Mail list logo
