1.9.0 bugs and feedback
Moderator: Forum Moderators
Forum rules
Before reporting issues in this section, you must read the following topic:
Before reporting issues in this section, you must read the following topic:
- TheBladeRoden
- Posts: 168
- Joined: July 16th, 2007, 8:01 am
Re: 1.9.0 bugs and feedback
+repnorbert wrote:Attachment...TheBladeRoden wrote:[...] Unless You Are Planning On Putting In Disco Music

Founding Father of Columbia
Re: 1.9.0 bugs and feedback
Do you have a savegame to reproduce this? Have you used some special addon amla or was it default? As thespaceinvader just wrote in IRC:Lord-Knightmare wrote:When a lvl 3 unit advances (AMLA), the game crashes.
Some more information might help. Any information (like the operating system used, how you got your binary ("official", built by yourself, ...), ...) might help. Please provide as much as possible.[21:18:14] <thespaceinvader> Ivanovic: I wonder whether that's some problem with non-default AMLA - I've AMLA'd level 3s without any problem
- Simons Mith
- Posts: 821
- Joined: January 27th, 2005, 10:46 pm
- Location: Twickenham
- Contact:
Re: 1.9.0 bugs and feedback
Standing animations: I was at the Albert Hall yesterday, and I had about 300 people who were all standing to study. So I did. OK, it was a classical music concert with unarmed humans, not an epic fantasy battle taking place over days, but I still think these are reasonable rules of thumb. The audience were probably about as still - or as fidgety - as I'd like to see them in-game.
Among the groundlings (well over 250), the predominant movement was to shift weight from one leg to the other and back again. Next most common was to move their arms - cross, uncross, put behind back, touch their faces or hair, maybe covering the odd cough or yawn. Then, head movements - Right, down, up, left, from most to least frequent. After that, gross movements such as sitting down, moving about, shifting weight to one leg for an extended period before moving back. These, being the largest movements, were also the least frequent. I was a bit surprised how rare looking to the left was, but it may have been because I was sitting at a point where the people I could see clearly had less reason to look to the left.
Among those 250+ people, yes, there was constant movement. But most of this movement (including 75%+ of the weight-shifting, which was the most common movement) would have been less than a pixel from side to side at Wesnoth scales. Also, some people were noticeably more fidgety than others throughout. I would estimate that at any given time no more than 10% were moving perceptibly, and of those moving, most of them still weren't moving enough to register at the pixel scale of Wesnoth units. If we say 5 in 250 were, that gives 2%, which would be one 1 unit in 50.
In the gallery, I could see about 30 people without craning my neck. Of those 30 standees, there were many occasions where no-one was moving at all. At most I noticed two people moving at once. Now, I know those balconies aren't that comfortable to lean on, so I think these two groups were reasonably comparable for fidgetiness.
Conclusion: A real-world fidget rate of 1 unit in 40-50 moving at any given time would roughly match what I saw. We probably want to increase that a bit for Wesnoth, to about 1 unit in 30, because we rarely have many dozens of units visible at once. This suggests the existing idle animation rate already covers ground-standing units adequately. Particularly as warm-blooded humans not under military discipline are probably more active than our saurians. So if our current 'fidget slider' went from 1 in 10 to 1 in 100, that would cover what I saw with a default slider setting of 1/3rd along.
I hope the animators find this summary useful.
It also struck me that we could give some units hidden traits: 'fidget': this unit executes an idle animation at twice the usual frequency; 'still': this unit executes idle animations at one quarter the usual frequency. And we could make chaotic units fidgetier during the night, and lawfuls during the day. And neutrals at dusk and dawn, so they don't feel left out.
Among the groundlings (well over 250), the predominant movement was to shift weight from one leg to the other and back again. Next most common was to move their arms - cross, uncross, put behind back, touch their faces or hair, maybe covering the odd cough or yawn. Then, head movements - Right, down, up, left, from most to least frequent. After that, gross movements such as sitting down, moving about, shifting weight to one leg for an extended period before moving back. These, being the largest movements, were also the least frequent. I was a bit surprised how rare looking to the left was, but it may have been because I was sitting at a point where the people I could see clearly had less reason to look to the left.
Among those 250+ people, yes, there was constant movement. But most of this movement (including 75%+ of the weight-shifting, which was the most common movement) would have been less than a pixel from side to side at Wesnoth scales. Also, some people were noticeably more fidgety than others throughout. I would estimate that at any given time no more than 10% were moving perceptibly, and of those moving, most of them still weren't moving enough to register at the pixel scale of Wesnoth units. If we say 5 in 250 were, that gives 2%, which would be one 1 unit in 50.
In the gallery, I could see about 30 people without craning my neck. Of those 30 standees, there were many occasions where no-one was moving at all. At most I noticed two people moving at once. Now, I know those balconies aren't that comfortable to lean on, so I think these two groups were reasonably comparable for fidgetiness.
Conclusion: A real-world fidget rate of 1 unit in 40-50 moving at any given time would roughly match what I saw. We probably want to increase that a bit for Wesnoth, to about 1 unit in 30, because we rarely have many dozens of units visible at once. This suggests the existing idle animation rate already covers ground-standing units adequately. Particularly as warm-blooded humans not under military discipline are probably more active than our saurians. So if our current 'fidget slider' went from 1 in 10 to 1 in 100, that would cover what I saw with a default slider setting of 1/3rd along.
I hope the animators find this summary useful.
It also struck me that we could give some units hidden traits: 'fidget': this unit executes an idle animation at twice the usual frequency; 'still': this unit executes idle animations at one quarter the usual frequency. And we could make chaotic units fidgetier during the night, and lawfuls during the day. And neutrals at dusk and dawn, so they don't feel left out.
-
- Posts: 462
- Joined: June 8th, 2006, 3:25 am
Re: 1.9.0 bugs and feedback
There's an issue with the handling of array indices in some tags in 1.9.0. If you do the following (where WML_MSG MSG does [wml_message] logger = err message = {MSG}):
You get output like this in stderr:
and attempting the following afterwards:
gives the error message "error engine: attempted to to replace ToD schedule with empty schedule". It seems that both of these tags have an off-by-1 error in their array index handling.
Edit - Silly me: Windows 7, English.
Edit - did some more testing. It seems to be a bug with the way some tags handle trailing array indices. Here are some more test runs with their result output (spoilered because the post is already pretty long):
Notice that [set_variables] handles all three cases correctly, while [store_time_of_day] handles "a" and "aaa[0].c" correctly, but interprets "aa[0]" as "aa[1]".
Code: Select all
[store_time_of_day]
variable=schedule
turn=1
[/store_time_of_day]
[store_time_of_day]
variable=schedule[1]
turn=1
[/store_time_of_day]
{WML_MSG "0: $schedule[0].id"}
{WML_MSG "1: $schedule[1].id"}
{WML_MSG "2: $schedule[2].id"}
Code: Select all
20100826 21:50:04 error wml: 0: dawn
20100826 21:50:04 error wml: 1:
20100826 21:50:04 error wml: 2: morning
Code: Select all
[insert_tag]
name=replace_schedule
variable=schedule[0]
[/insert_tag]
Edit - Silly me: Windows 7, English.
Edit - did some more testing. It seems to be a bug with the way some tags handle trailing array indices. Here are some more test runs with their result output (spoilered because the post is already pretty long):
Spoiler:
Re: 1.9.0 bugs and feedback
I don't think there are many broken tags, but [store_time_of_day] is definitely one of them. The tag just disregards any explicit trailing index and systematically appends a variable with the given name. But since you mentioned an index, it caused the engine to first create that other variable. So, when you mention the second [schedule] ("schedule[1]"), the engine creates an empty one, and then it appends another [schedule] with the values in it ("schedule[2]").Exasperation wrote:It seems to be a bug with the way some tags handle trailing array indices.
To summarize, don't use [store_time_of_day] with an explicit index, and make sure you know exactly how many variables there are with the same name. In your case, you better store to a temporary variable and then use [set_variables] to transfer its content to its final destination, since [set_variables] has a much saner semantic.
- CheeseLord
- Posts: 147
- Joined: February 19th, 2009, 11:07 am
- Location: Knagla
Re: 1.9.0 bugs and feedback
Hi guys:
Here's a bug I just found ...
OS: Windows 7
Version: 1.9.0
Sry about not being able to say much else - It looks like it probably is a simple tag missed out or something, but meh, I'm no programmer!!
Here's a bug I just found ...
OS: Windows 7
Version: 1.9.0
Sry about not being able to say much else - It looks like it probably is a simple tag missed out or something, but meh, I'm no programmer!!

- Attachments
-
stderr.txt
- Bug
- (9.58 KiB) Downloaded 217 times
Lord of Cheese.....especially Parmesan!!!
None shall stand against the Dwarfs in their homeland
Top 3 quotes by a developer:
1. Locked
2. Do it yourself
3. "No"
None shall stand against the Dwarfs in their homeland
Top 3 quotes by a developer:
1. Locked
2. Do it yourself
3. "No"
Re: 1.9.0 bugs and feedback
It's fixed already. If you want to fix it for yourself so you can play the next scenario, just change id=Revenge to id=12_Revenge in Wesnoth/data/campaigns/Dead_Water/scenarios/12_Revenge.cfg:7.CheeseLord wrote:Here's a bug I just found ...
- CheeseLord
- Posts: 147
- Joined: February 19th, 2009, 11:07 am
- Location: Knagla
Re: 1.9.0 bugs and feedback
Ooooo yay!!! Thanks a lot zookeeper
.. *skips off to pwn undead*

Lord of Cheese.....especially Parmesan!!!
None shall stand against the Dwarfs in their homeland
Top 3 quotes by a developer:
1. Locked
2. Do it yourself
3. "No"
None shall stand against the Dwarfs in their homeland
Top 3 quotes by a developer:
1. Locked
2. Do it yourself
3. "No"
Re: 1.9.0 bugs and feedback
I'm sorry, but were those people in full battle attire? Were they breathing heavily after running all the way from the castle to the middle of the field? Even then: WINR.Simons Mith wrote:Standing animations: *snip*
edit: Were they magical lizards?
- Simons Mith
- Posts: 821
- Joined: January 27th, 2005, 10:46 pm
- Location: Twickenham
- Contact:
Re: 1.9.0 bugs and feedback
You're not addressing the core objection: it's bad animation to have things moving when they shouldn't be, just as it's bad not to animate things that should be moving. Although the latter is more understandable given limited resources. Nail that objection first, please, then worry about the more nitpicky stuff afterwards.Gambit wrote:I'm sorry, but were those people in full battle attire? Were they breathing heavily after running all the way from the castle to the middle of the field? Even then: WINR.Simons Mith wrote:Standing animations: *snip*
edit: Were they magical lizards?
Re: 1.9.0 bugs and feedback
Even sticking with nitpicky stuff, I don't think it supports bobbing animations. American football players have armor-ish pads & helmets, run around, and get out of breath. To the extent you can tell they are breathing hard, it is not because they are bobbing and dancing. It is true that most of them are not magical lizards, but same is true for most of the other wesnoth factions which are presumably going to get these animations as well.Simons Mith wrote:You're not addressing the core objection: it's bad animation to have things moving when they shouldn't be, just as it's bad not to animate things that should be moving. Although the latter is more understandable given limited resources. Nail that objection first, please, then worry about the more nitpicky stuff afterwards.Gambit wrote: I'm sorry, but were those people in full battle attire? Were they breathing heavily after running all the way from the castle to the middle of the field? Even then: WINR.
edit: Were they magical lizards?
As for WINR, well, there is no way to reply to that. Maybe Wesnoth Is Not Street Fighter?
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: 1.9.0 bugs and feedback
OS: Win Vista SP2
Wesnoth v1.9.0, no additions, etc.
Not sure how to reproduce this or give a clue how it happened, but last night I stayed up and played the Southern Guard campaign, reached the ... (mission with the Dark Lake and the fog. Sorry that I can't remember the name P:) (after the Valley of Tears, I think it was) ... and I lost. So, I went to load my game, and decided instead that I'd just go to sleep. The saves were all there.
I loaded Wesnoth today and my settings were default and my saves were nonexistent. Don't know if this is a glitch of some kind or a legit bug, but there you have it.
If it's any help, my settings were default to begin with, aside from the resolution changed to 1200x800 and display set to "Full Screen". I'm not a programmer, so I'm not sure of anything else that could be of use.
EDIT: Okay, I've found the problem. When I load Wesnoth directly from the programfile\wesnoth (or from the shortcut thereof), it opens wesnoth with what appears to be a separate save file / settings file. (I opened Wesnoth 1.9.0 originally in the start menu through all programs ---> battle for wesnoth ---> wesnoth.) Apparently they're two separate files? I can't be sure.
I read through some of the other issues, and I hope this hasn't already been posted.
As a last note, I just downloaded the game last night, and it's looking great in all aspects.
Wesnoth v1.9.0, no additions, etc.
Not sure how to reproduce this or give a clue how it happened, but last night I stayed up and played the Southern Guard campaign, reached the ... (mission with the Dark Lake and the fog. Sorry that I can't remember the name P:) (after the Valley of Tears, I think it was) ... and I lost. So, I went to load my game, and decided instead that I'd just go to sleep. The saves were all there.
I loaded Wesnoth today and my settings were default and my saves were nonexistent. Don't know if this is a glitch of some kind or a legit bug, but there you have it.
If it's any help, my settings were default to begin with, aside from the resolution changed to 1200x800 and display set to "Full Screen". I'm not a programmer, so I'm not sure of anything else that could be of use.
EDIT: Okay, I've found the problem. When I load Wesnoth directly from the programfile\wesnoth (or from the shortcut thereof), it opens wesnoth with what appears to be a separate save file / settings file. (I opened Wesnoth 1.9.0 originally in the start menu through all programs ---> battle for wesnoth ---> wesnoth.) Apparently they're two separate files? I can't be sure.
I read through some of the other issues, and I hope this hasn't already been posted.
As a last note, I just downloaded the game last night, and it's looking great in all aspects.

Last edited by Killcycle on August 28th, 2010, 10:49 pm, edited 2 times in total.
Re: 1.9.0 bugs and feedback
Oh, and the Previous / Next buttons on the opening screen (for the little tactical hints) sends me to a "The End" credits screen. Again, hope this hasn't already been posted.
-
- macOS Packager
- Posts: 239
- Joined: April 17th, 2004, 5:16 pm
- Location: Ontario, Canada
- Contact:
Re: 1.9.0 bugs and feedback
That's because the shortcut opens the game with command-line parameters that tell it where your data is. It's still opening the same program, just opening it with different settings.
Re: 1.9.0 bugs and feedback
Not entirely sure how that works, but I'm glad it's not anything serious - since they're the same file, at least I thought. Any way to make the data available to both?penguin wrote:That's because the shortcut opens the game with command-line parameters that tell it where your data is. It's still opening the same program, just opening it with different settings.