recruiting impossible on some parts of a castle

The map was pointed out to be pointless, but I believe it has some sense in it. It is still under construction. The idea however, is to have separate areas of action that are almost separated from each other. Ofcourse you can move your unit from one place of action to another, but it is _very_ expensive, as the map is so big. The size of the map is not a problem because you don't have to move your units long distances as each player has a recruiting point at each relevant location. So with this map you end up having multiple mini games and then the problem for participating players is to divide their resources between those small areas of action. Because, as I said earlier, moving the units from one place to another later on is really expensive.

Thank you for taking the time to report this bug and helping to make Ubuntu better.I took a look at the map, and it looks very interesting.

It would be appreciated if you could provide more information to your bug report. Please state the version of Ubuntu and the version of the Wesnoth package you are running. You can check the version of the Wesnoth package installed by looking in Synaptic or another package manager.

I confirm this bug in Ubuntu 8.04 using the Wesnoth 1:1.4.4-2 package from Debian unstable.

Based on several test maps (attached), I have determined that Wesnoth does not allow you to recruit more than 99 hexes away. The distance is measured along the path of castles. This means that if the path of castles is curved, the last recruitable hex will be closer to the leader, as the path is longer. Please do not hesitate to ask for more detail in my explanation if you did not understand what I mean.

This bug needs to be forwarded upstream, as this is almost certainly a Wesnoth issue, not a packaging issue with Debian or Ubuntu. Being short on time here, I have marked it for forwarding upstream. You are welcome to forward it yourself by filing a bug at http://bugs.wesnoth.org/ and linking it here, or I will try to do so when I get a chance. In the meantime, anyone can check to see if the bug exists on other platforms (Microsoft Windows and Apple Mac OS X) and other GNU/Linux distributions.

Reported upstream.

Ugh, Launchpad refuses to accept the URL of the upstream bug.

https://gna.org/bugs/index.php?12185

Added upstream bug watch by removing "index.php" from the URL of the upstream bug.

Fixed upstream on August 20 by Eric Raymond in trunk (SVN revision 28805): http://svn.gna.org/viewcvs/wesnoth/?rev=28805&view=rev

It should be fixed in the next development release (1.5.x), 1.5.4.

The Battle for Wesnoth 1.5.4 was released a few minutes ago. Marking as fixed.

Not in Ubuntu yet, marking as fix committed.

Fixed committed should be used when the changes are pending and to be uploaded soon. Wesnoth 1.5.4 is an upstream development release (odd version number) and will not be included in Ubuntu or Debian unstable (for future syncing). For the bug to be fixed in Ubuntu, Wesnoth 1.6.x (stable release) will first need to be released by upstream and packaged by Debian unstable. Reverting to Confirmed status.

If you want the fix to this bug immediately, you can either get Wesnoth 1.5.4 directly from Wesnoth (no packaging) or from Debian experimental.

 This is ... a quite strange bug trace. Starting off with marking the bug as forwarded but not actually forwarding it. But ... well, having the fix right at the hands why was it never tried to apply it to the 1.4 branch? Especially since the fix is just a small change to some computation, and the commit is also directly linked in here?

I mean, it was reported against 1.4.4, was fixed before 1.4.5 got uploaded, we are now at 1.4.7. Is this really considered user support? Yes, it's a minor issue, but likewise, it's an even more minor fix that should had been able to get applied at any time. Or if you don't want to apply it to the Ubuntu package to create an extra patch set for that, at least had let me know so I could apply it in Debian and you just sync again?

Sorry, but I'm quite a fair bit disappointed by reading this ...

http://svn.debian.org/viewsvn/pkg-games?rev=8504&view=rev

I'm not sure how quick I will (be able to) actually upload the package with that change, at least it won't get lost and will be in the next upload of the package to Debian - and from there synced to Ubuntu. Sorry, Toni, that your fellow Ubuntu people didn't really go that way. I have no idea why not, it just disappoints me, but marking something as forwarded and not actually doing it gives an idea of why it might not had been done.

I think it was forwarded directly to Wesnoth developers and got fixed there.
The link to their bug tracker ( https://gna.org/bugs/?12185 ) is available at the top of this page.

Alright, after speaking with upstream adding that to the 1.4 branch is a no-go, and I will have to revert the change. This will produce Out-of-Sync problems amongst different 1.4* users and become a hell to debug.

So you really will have to wait for the 1.6 release. 1.4.7 is said to be the last 1.4 release, there is plans to have first release candidates for 1.6 in january from what I heard, so it might well be that this will be fixed before Jaunty gets released for you. Keep fingers crossed. :)

* Toni Ruottu <email address hidden> [2008-12-14 15:52:48 CET]:
> I think it was forwarded directly to Wesnoth developers and got fixed there.
> The link to their bug tracker ( https://gna.org/bugs/?12185 ) is available at the top of this page.

 Yes, but I was refering to Dara Adib's message from August 10th. The
bug was marked as forwarded for six days without actually haven't been
done so. Where I understand that one is short of time, one shouldn't
claim a thing that isn't done - this might be quite confusing and gets
issues overlooked in the long run.

 Anyway, like said in my last message, you'll have to wait for the 1.6
release candidate releases, we don't want to produce incompatible
versions along the 1.4 branch. Or, like suggested already by Dara, you
could use the packages from Debian experimental which are tracking the
1.5 branch.

 Sorry for the confusion,
Rhonda

> Yes, but I was refering to Dara Adib's message from August 10th. The
> bug was marked as forwarded for six days without actually haven't been
> done so. Where I understand that one is short of time, one shouldn't
> claim a thing that isn't done - this might be quite confusing and gets
> issues overlooked in the long run.

It was marked as "need to be forwarded to an upstream bug tracker", not as forwarded. In Launchpad, this is accomplished by adding an upstream bug task without providing a URL for the upstream bug.

Source: https://wiki.ubuntu.com/Bugs/HowToTriage#Marking%20a%20Bug%20as%20Requiring%20Forwarding

This bug was fixed in the package wesnoth - 1:1.4.7-3

---------------
wesnoth (1:1.4.7-3) unstable; urgency=low

  * Revert change in last revision - it would impose a compatibility issue.
    Will be fixed with first release candidate of 1.6.

wesnoth (1:1.4.7-2) unstable; urgency=low

  * Fetch upstream revision 28805 to allow recruit more than 99 castle tiles
    away (LP: #256345). Have fun, Toni!

wesnoth (1:1.4.7-1) unstable; urgency=low

  * New stable upstream release, bugfixes and translation updates, fixing:
    - gcc 4.4 FTBFS (closes: #505957)

 -- Ubuntu Archive Auto-Sync <email address hidden> Mon, 15 Dec 2008 10:21:36 +0000

The mentioned "Fix released" was reverted, so reopening the bug

The Battle for Wesnoth 1.6a reached Ubuntu Jaunty.