Wesnoth 1.11.16 (1.12 beta 6)
Moderator: Forum Moderators
Re: Wesnoth 1.11.16 (1.12 beta 6)
2. Hmm it looks fine to me, I see Frozen at the top of the list: http://i.imgur.com/6gn65q6.png?1
4. This is a known bug, listed in the first post of this thread. Sometime in 1.11.x series someone decided to refactor the map labels but they didn't test mp... their commit message says they didn't think that it would break mp, but turns out it does. Not going to name names, I am hoping that they will come back and fix this.
5. That is indeed wierd... thanks for report. It looks like chat is just totally disabled in a local game. I think that's not good, some scenarios may use [chat] tags anyways and then I doubt they would work.
No comment on 1 and 3, I think someone who knows more about wesnoth images should figure out what's up with 1.
4. This is a known bug, listed in the first post of this thread. Sometime in 1.11.x series someone decided to refactor the map labels but they didn't test mp... their commit message says they didn't think that it would break mp, but turns out it does. Not going to name names, I am hoping that they will come back and fix this.
5. That is indeed wierd... thanks for report. It looks like chat is just totally disabled in a local game. I think that's not good, some scenarios may use [chat] tags anyways and then I doubt they would work.
No comment on 1 and 3, I think someone who knows more about wesnoth images should figure out what's up with 1.
Re: Wesnoth 1.11.16 (1.12 beta 6)
[chat] and wesnoth.message indeed work but they arent in log anyways (thought it would be nice if they were).
Re: Wesnoth 1.11.16 (1.12 beta 6)
Grand Knight just needs its "image_icon" defined, like the Paladin has.Bob_The_Mighty wrote:1. The Grand Knight unit image doesn't display properly in the righthand panel - it's squashed, slightly too big and blurry. Obviously it's bigger than the standard 72x72 so is this unavoidable?
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: Wesnoth 1.11.16 (1.12 beta 6)
Regarding 5: It looks like it has been this way even since 1.11.0, so... 2 years ago?
Having the bug in between version tags is really annoying to figure out what went wrong... also I went back 250 pages in commits to somewhere random in between 1.11.0 and 1.10.7, and it looks like I can't compile any of those commits because of some weird boost error... it looks like maybe we were on a much older version back then...?
So, long story short I have no idea when this was changed or how (best guess spring of 2012?), and fixing it will probably have to be done the hard way.
Having the bug in between version tags is really annoying to figure out what went wrong... also I went back 250 pages in commits to somewhere random in between 1.11.0 and 1.10.7, and it looks like I can't compile any of those commits because of some weird boost error... it looks like maybe we were on a much older version back then...?
So, long story short I have no idea when this was changed or how (best guess spring of 2012?), and fixing it will probably have to be done the hard way.
- Bob_The_Mighty
- Posts: 870
- Joined: July 13th, 2006, 1:15 pm
Re: Wesnoth 1.11.16 (1.12 beta 6)
Thanks for picking up on the problems I posted. I've now found two more:
6. An ai side with lots of units set to ai_special=guardian takes an uncommonly long time to take its turn, even when there are no enemies nearby and thus no actual movement taking place. I'm guessing the new micro ai system has changed this somehow.
7. In multiplayer games, ai leaders who are given specific names in their side definition are now defaulting to the name of the host. I'm having lots of conversations with multiple Bob_The_Mightys, which is unnerving. I've noticed the full changelog mentions the introduction of a [leader] tag back in Version 1.9.5 (it's not mentioned on the wiki as far as I can see). I've tried using this inside a [side] definition, but it simply created a random leader called Bob_The_Mighty on top of the one defined in [leader]. Both units appeared on the map. I tried using no_leader=yes just before my [leader] tag, but this had an unexpected effect too: the leader's type, gender and other details were correct, but they are still called Bob_The_Mighty. What's the correct way to handle this?
6. An ai side with lots of units set to ai_special=guardian takes an uncommonly long time to take its turn, even when there are no enemies nearby and thus no actual movement taking place. I'm guessing the new micro ai system has changed this somehow.
7. In multiplayer games, ai leaders who are given specific names in their side definition are now defaulting to the name of the host. I'm having lots of conversations with multiple Bob_The_Mightys, which is unnerving. I've noticed the full changelog mentions the introduction of a [leader] tag back in Version 1.9.5 (it's not mentioned on the wiki as far as I can see). I've tried using this inside a [side] definition, but it simply created a random leader called Bob_The_Mighty on top of the one defined in [leader]. Both units appeared on the map. I tried using no_leader=yes just before my [leader] tag, but this had an unexpected effect too: the leader's type, gender and other details were correct, but they are still called Bob_The_Mighty. What's the correct way to handle this?
My current projects:
MP pirate campaign: The Altaz Mariners
RPG sequel: Return to Trent
MP stealth campaign: Den of Thieves
MP pirate campaign: The Altaz Mariners
RPG sequel: Return to Trent
MP stealth campaign: Den of Thieves
Re: Wesnoth 1.11.16 (1.12 beta 6)
Hmm, interesting, but I don't see how it could have anything to do with the Micro AIs. The MAIs are an additional layer to the normal AI and when they aren't used, AI behavior is not affected by them at all (neither evaluation nor execution). So it must be something else. I can have a look if I see something suspicious, but I don't really know much about that part of the AI code.Bob_The_Mighty wrote:6. An ai side with lots of units set to ai_special=guardian takes an uncommonly long time to take its turn, even when there are no enemies nearby and thus no actual movement taking place. I'm guessing the new micro ai system has changed this somehow.
Edit:
I did some tests, putting 100 guardians with no enemy unit in reach into a scenario. It does indeed take much longer in 1.11.16+dev than in 1.10.7. Looking at the debug log output, the reason does not seem to be that the individual move evaluation takes much longer (it does, but only by about 10-15%), but that in 1.10.7 there are many guardians for which the move evaluation takes no time at all (72 out of the 100), while that is the case for only 21/100 in 1.11.16. I have no idea why that is the case, and I'm not really very qualified to investigate this either. My best guess would be that caching works differently now, but whether that's due to a problem in 1.11 or due to a bug fix, I really can't say. And it's just a semi-random guess in the first place...
Just for reference, I attach the timing log outputs:
1.10.7:
Code: Select all
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 64ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 63ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 64ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 64ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 67ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 64ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 64ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:57 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 65ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 65ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 65ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 64ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 65ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 65ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 63ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 64ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 63ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 65ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:58 } END: choosing move (took 1ms)
20140908 12:51:58 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 67ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 64ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 66ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 65ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 64ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 65ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 64ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 64ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 66ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 0ms)
20140908 12:51:59 } END: choosing move (took 65ms)
Code: Select all
20140908 12:55:25 } END: choosing move (took 118ms)
20140908 12:55:25 } END: choosing move (took 80ms)
20140908 12:55:25 } END: choosing move (took 77ms)
20140908 12:55:26 } END: choosing move (took 76ms)
20140908 12:55:26 } END: choosing move (took 75ms)
20140908 12:55:26 } END: choosing move (took 78ms)
20140908 12:55:26 } END: choosing move (took 78ms)
20140908 12:55:26 } END: choosing move (took 77ms)
20140908 12:55:26 } END: choosing move (took 74ms)
20140908 12:55:26 } END: choosing move (took 73ms)
20140908 12:55:27 } END: choosing move (took 73ms)
20140908 12:55:27 } END: choosing move (took 77ms)
20140908 12:55:27 } END: choosing move (took 76ms)
20140908 12:55:27 } END: choosing move (took 75ms)
20140908 12:55:27 } END: choosing move (took 80ms)
20140908 12:55:27 } END: choosing move (took 72ms)
20140908 12:55:27 } END: choosing move (took 73ms)
20140908 12:55:27 } END: choosing move (took 74ms)
20140908 12:55:27 } END: choosing move (took 72ms)
20140908 12:55:28 } END: choosing move (took 72ms)
20140908 12:55:28 } END: choosing move (took 72ms)
20140908 12:55:28 } END: choosing move (took 73ms)
20140908 12:55:28 } END: choosing move (took 72ms)
20140908 12:55:28 } END: choosing move (took 73ms)
20140908 12:55:28 } END: choosing move (took 74ms)
20140908 12:55:28 } END: choosing move (took 74ms)
20140908 12:55:28 } END: choosing move (took 73ms)
20140908 12:55:29 } END: choosing move (took 75ms)
20140908 12:55:29 } END: choosing move (took 72ms)
20140908 12:55:29 } END: choosing move (took 72ms)
20140908 12:55:29 } END: choosing move (took 74ms)
20140908 12:55:29 } END: choosing move (took 75ms)
20140908 12:55:29 } END: choosing move (took 73ms)
20140908 12:55:29 } END: choosing move (took 73ms)
20140908 12:55:29 } END: choosing move (took 76ms)
20140908 12:55:29 } END: choosing move (took 73ms)
20140908 12:55:30 } END: choosing move (took 76ms)
20140908 12:55:30 } END: choosing move (took 96ms)
20140908 12:55:30 } END: choosing move (took 76ms)
20140908 12:55:30 } END: choosing move (took 79ms)
20140908 12:55:30 } END: choosing move (took 77ms)
20140908 12:55:30 } END: choosing move (took 77ms)
20140908 12:55:30 } END: choosing move (took 77ms)
20140908 12:55:30 } END: choosing move (took 76ms)
20140908 12:55:30 } END: choosing move (took 74ms)
20140908 12:55:31 } END: choosing move (took 74ms)
20140908 12:55:31 } END: choosing move (took 76ms)
20140908 12:55:31 } END: choosing move (took 78ms)
20140908 12:55:31 } END: choosing move (took 74ms)
20140908 12:55:31 } END: choosing move (took 73ms)
20140908 12:55:31 } END: choosing move (took 74ms)
20140908 12:55:31 } END: choosing move (took 73ms)
20140908 12:55:31 } END: choosing move (took 73ms)
20140908 12:55:31 } END: choosing move (took 75ms)
20140908 12:55:32 } END: choosing move (took 75ms)
20140908 12:55:32 } END: choosing move (took 73ms)
20140908 12:55:32 } END: choosing move (took 73ms)
20140908 12:55:32 } END: choosing move (took 74ms)
20140908 12:55:32 } END: choosing move (took 73ms)
20140908 12:55:32 } END: choosing move (took 73ms)
20140908 12:55:32 } END: choosing move (took 73ms)
20140908 12:55:32 } END: choosing move (took 0ms)
20140908 12:55:32 } END: choosing move (took 73ms)
20140908 12:55:32 } END: choosing move (took 0ms)
20140908 12:55:32 } END: choosing move (took 73ms)
20140908 12:55:32 } END: choosing move (took 0ms)
20140908 12:55:33 } END: choosing move (took 75ms)
20140908 12:55:33 } END: choosing move (took 0ms)
20140908 12:55:33 } END: choosing move (took 73ms)
20140908 12:55:33 } END: choosing move (took 0ms)
20140908 12:55:33 } END: choosing move (took 73ms)
20140908 12:55:33 } END: choosing move (took 0ms)
20140908 12:55:33 } END: choosing move (took 73ms)
20140908 12:55:33 } END: choosing move (took 0ms)
20140908 12:55:33 } END: choosing move (took 76ms)
20140908 12:55:33 } END: choosing move (took 0ms)
20140908 12:55:33 } END: choosing move (took 73ms)
20140908 12:55:33 } END: choosing move (took 1ms)
20140908 12:55:33 } END: choosing move (took 77ms)
20140908 12:55:33 } END: choosing move (took 0ms)
20140908 12:55:33 } END: choosing move (took 74ms)
20140908 12:55:33 } END: choosing move (took 1ms)
20140908 12:55:33 } END: choosing move (took 72ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 73ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 72ms)
20140908 12:55:34 } END: choosing move (took 1ms)
20140908 12:55:34 } END: choosing move (took 75ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 73ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 73ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 72ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 71ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 0ms)
20140908 12:55:34 } END: choosing move (took 75ms)
SP campaigns: Galuldur's First Journey (1.12 & 1.14) & Grnk the Mighty (1.10 & 1.12)
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
- Bob_The_Mighty
- Posts: 870
- Joined: July 13th, 2006, 1:15 pm
Re: Wesnoth 1.11.16 (1.12 beta 6)
Mattsc, I appreciate you looking into the guardian issue. However, in the meantime I've come across another two problems:
8. Deactivating planning mode doesn't remove already planned moves.
9. This might be nothing new, but when reloading an autosave of an MP campaign the host is given control of all ai sides.
8. Deactivating planning mode doesn't remove already planned moves.
9. This might be nothing new, but when reloading an autosave of an MP campaign the host is given control of all ai sides.
My current projects:
MP pirate campaign: The Altaz Mariners
RPG sequel: Return to Trent
MP stealth campaign: Den of Thieves
MP pirate campaign: The Altaz Mariners
RPG sequel: Return to Trent
MP stealth campaign: Den of Thieves
Re: Wesnoth 1.11.16 (1.12 beta 6)
Bob:
Regarding (6): Barring someone like Crab appearing and explaining what happened, I think the most likely way to fix something like this is to profile the code to see what is up. A good poor man's profiling technique is to run wesnoth through a debugger like gdb, play to the point where it is being very slow, and then hit ctrl-break to interrupt the program, and generate a backtrace from that point. Then we have some functions / line numbers to work with, and if we do it a few times and the same culprits appear repeatedly we can try to figure out why. For this either you or mattsc need to post a scenario / savefile where the slow behavior is observed.
This kind of thing might be easy to fix or it might not -- often it's hard to guess why a program is slow, but given mattsc's info above it looks like your guess was on the money.
Regarding (8): I think it always worked this way. The way I understood, turning on planning mode makes your clicks generate planned actions instead of real actions. If you leave some planned actions on the queue and disable planning mode, you can then perform real actions, which may invalidate the planned actions, or it might not, they should get removed if they don't make sense anymore. That being said, don't try any of that in a networked mp game because crashes have been observed esp. when executing planned attack actions in networked mode. (This is observed in 1.10, don't know if it is reproduced in 1.12 but I don't think anyone has really touched the relevant code.)
Regarding (9): I thought we had fixed this kind of issue, but I don't remember testing autosaves. If not we probably can fix it.
Edit:
I fixed 3 and 5 above. 5 turned out to be easier than I thought it would be.
(3) https://github.com/wesnoth/wesnoth/comm ... c5289574f2
(5) https://github.com/wesnoth/wesnoth/pull/282
Regarding (6): Barring someone like Crab appearing and explaining what happened, I think the most likely way to fix something like this is to profile the code to see what is up. A good poor man's profiling technique is to run wesnoth through a debugger like gdb, play to the point where it is being very slow, and then hit ctrl-break to interrupt the program, and generate a backtrace from that point. Then we have some functions / line numbers to work with, and if we do it a few times and the same culprits appear repeatedly we can try to figure out why. For this either you or mattsc need to post a scenario / savefile where the slow behavior is observed.
This kind of thing might be easy to fix or it might not -- often it's hard to guess why a program is slow, but given mattsc's info above it looks like your guess was on the money.
Regarding (8): I think it always worked this way. The way I understood, turning on planning mode makes your clicks generate planned actions instead of real actions. If you leave some planned actions on the queue and disable planning mode, you can then perform real actions, which may invalidate the planned actions, or it might not, they should get removed if they don't make sense anymore. That being said, don't try any of that in a networked mp game because crashes have been observed esp. when executing planned attack actions in networked mode. (This is observed in 1.10, don't know if it is reproduced in 1.12 but I don't think anyone has really touched the relevant code.)
Regarding (9): I thought we had fixed this kind of issue, but I don't remember testing autosaves. If not we probably can fix it.
Edit:
I fixed 3 and 5 above. 5 turned out to be easier than I thought it would be.
(3) https://github.com/wesnoth/wesnoth/comm ... c5289574f2
(5) https://github.com/wesnoth/wesnoth/pull/282
- The_Afterman
- Posts: 50
- Joined: August 7th, 2012, 6:32 pm
Re: Wesnoth 1.11.16 (1.12 beta 6)
Release date window?
Re: Wesnoth 1.11.16 (1.12 beta 6)
Current behavior of [modification] looks uncomfortable for user: If a scenario where modification is not allowed is chosen, interface ask user to desactivate it.
I think if [modification] where automatically disabled without user have to take any care, would be more desirable. Right now I feel like introducing a [modification] only valid for my add on, would make users hate me
I think if [modification] where automatically disabled without user have to take any care, would be more desirable. Right now I feel like introducing a [modification] only valid for my add on, would make users hate me
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
World Conquest II
Re: Wesnoth 1.11.16 (1.12 beta 6)
Done in commit 396b4356b1a1.doofus-01 wrote:Grand Knight just needs its "image_icon" defined, like the Paladin has.Bob_The_Mighty wrote:1. The Grand Knight unit image doesn't display properly in the righthand panel - it's squashed, slightly too big and blurry. Obviously it's bigger than the standard 72x72 so is this unavoidable?
SP campaigns: Galuldur's First Journey (1.12 & 1.14) & Grnk the Mighty (1.10 & 1.12)
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on