Possible bug?
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:
- Spannerbag
- Posts: 535
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Possible bug?
Hi,
I recently published the UMC campaign AfterEI which was mostly developed and tested on earlier versions of Wesnoth (mostly 14.7).
I'm pretty sure I tested these pathways on 14.7 and IIRC never saw this behaviour in that version.
However a player took the trouble to report a bug to me and I have been able to replicate this.
In the process of investigating this issue I have stumbled across (and mostly fixed) other warnings/errors in the logfile that only appear after I load my campaign (not seen what happens loading other campaigns as it's late here and I've a busy day tomorrow!).
First, what I think might be a bug.
Situation
In this scenario the player begins with leaders that were bit-players in an earlier scenario and the "main" (side 1) leader (Flynn) is in a stored variable.
There are 2 conditions under which this stored leader is reinstated:
a) on a specific turn
b) if all enemies are dead.
And the actual event is:
In both cases thing seems to work, Flynn & co appear, Flynn issues dialogue and side 1 is unhidden.
NOTE: the above was in a
In case a) above everything works fine.
But in case b) side 1 (Flynn) is not mentioned in the endlevel gold bonus and also the next scenaio begins with a leader of Flynn's unittype but as defined right at the campaign start. Name is randomly generated. Also, all the side 1 recalls are missing and in the next scenario the player automatically loses (this was the bug the player reported to me). Note that side 1 troops are not stored in a variable but remain in the recall list.
Now as both cases execute the same code (in an event) I don't think the issue is there. It seems as if the game doesn't properly update side 1 (presumably because a side 1 turn event is never executed?).
Additional wrinkles
The logfile kept issuing warnings and errors and as quick as I fixed some, more appeared.
Some were trivial (I removed some utf 8 BOM characters and have replaced
However there was one (now two) that have appeared that I can't find any (useful) information to help and I'm getting out of my depth.
FWIW here's the latest log file:
The two I can't work out are:
I have gone through all instances for side 5, [goal], AI_CA and can't find what sets this off.
This one only recently appeared.
Also these ony appear after I load AfterEI.
The 'AEIBN' and 'stub' warnings are OK, the first is something I'm mucking about with and the second is my little test stub campaign for trying stuff out.
I attach a pdf with screen dumps from the player (not me) that might help?
I'd really rather not bother the player just now as his last PM to me indicated he was very busy indeed.
Any advice on whether these ai issues are significant - and if so how to resolve them - would be appreciated.
If this isn't a bug but something broken in my code, please let me know and apologies for posting this!
Cheers,
Spannerbag
I recently published the UMC campaign AfterEI which was mostly developed and tested on earlier versions of Wesnoth (mostly 14.7).
I'm pretty sure I tested these pathways on 14.7 and IIRC never saw this behaviour in that version.
However a player took the trouble to report a bug to me and I have been able to replicate this.
In the process of investigating this issue I have stumbled across (and mostly fixed) other warnings/errors in the logfile that only appear after I load my campaign (not seen what happens loading other campaigns as it's late here and I've a busy day tomorrow!).
First, what I think might be a bug.
Situation
In this scenario the player begins with leaders that were bit-players in an earlier scenario and the "main" (side 1) leader (Flynn) is in a stored variable.
There are 2 conditions under which this stored leader is reinstated:
a) on a specific turn
Code: Select all
[event] # Flynn finally arrives
name=turn {FLYNN_ARRIVE}
[fire_event] # Implemented as [event] as could be also called by early victory
name=flynn_arrives
[/fire_event]
...
Code: Select all
# Victory: all ants and Orcs dead
[event]
name=last breath
[filter]
side=4,5
[/filter]
[filter_condition]
[have_unit]
side=4,5
count=0
[/have_unit]
[variable] # =yes when Orcs arrive
name=orcs_arrive_flag
equals=yes
[/variable]
[/filter_condition]
[if] # If player wins before Flynn arrives then unstore him
[have_unit]
id=Flynn
side=1
count=0
[/have_unit]
[then]
[fire_event] # Implemented as [event], also fires on turn {FLYNN_ARRIVE}
name=flynn_arrives
[/fire_event]
...
And the actual event is:
Code: Select all
[event] # Flynn arrival event
name=flynn_arrives
[modify_side]
side=1
income=0
hidden=no
[/modify_side]
[music]
name=loyalists.ogg
immediate=yes
append=yes
[/music]
[unstore_unit]
variable=AEI_Flynn
x,y=29,18
[/unstore_unit]
[clear_variable]
name=AEI_Flynn
[/clear_variable]
[recall]
id=Pierce
side=1
x,y=29,19
[/recall]
[recall]
id=Zipp
side=1
x,y=30,17
[/recall]
[recall]
id=Dirk
side=1
x,y=29,17
[/recall]
[recall]
id=Scampa
side=1
x,y=30,18
[/recall]
[/event]
NOTE: the above was in a
die
event but I changed it to last breath
to see if that did anything, but the behaviour didn't change...In case a) above everything works fine.
But in case b) side 1 (Flynn) is not mentioned in the endlevel gold bonus and also the next scenaio begins with a leader of Flynn's unittype but as defined right at the campaign start. Name is randomly generated. Also, all the side 1 recalls are missing and in the next scenario the player automatically loses (this was the bug the player reported to me). Note that side 1 troops are not stored in a variable but remain in the recall list.
Now as both cases execute the same code (in an event) I don't think the issue is there. It seems as if the game doesn't properly update side 1 (presumably because a side 1 turn event is never executed?).
Additional wrinkles
The logfile kept issuing warnings and errors and as quick as I fixed some, more appeared.
Some were trivial (I removed some utf 8 BOM characters and have replaced
message=
with label=
to remove some of the chaff.However there was one (now two) that have appeared that I can't find any (useful) information to help and I'm getting out of my depth.
FWIW here's the latest log file:
Code: Select all
Battle for Wesnoth v1.14.9
Started on Wed Dec 11 00:08:29 2019
Automatically found a possible data directory at C:\Program Files (x86)\Battle for Wesnoth 1.14.9
Data directory: C:\Program Files (x86)\Battle for Wesnoth 1.14.9
User configuration directory: C:\Users\USER\Documents\My Games\Wesnoth1.14
User data directory: C:\Users\USER\Documents\My Games\Wesnoth1.14
Cache directory: C:\Users\USER\Documents\My Games\Wesnoth1.14\cache
Setting mode to 1366x768
20191211 00:08:34 warning general: no location found for 'data/add-ons/AEIBN/translations', skipping textdomain
20191211 00:08:34 warning general: no location found for 'data/add-ons/Oath_of_Allegiance/translations', skipping textdomain
20191211 00:08:34 warning general: no location found for 'data/add-ons/UMC_Terrain_Pack_Old/translations', skipping textdomain
20191211 00:08:34 warning general: no location found for 'data/add-ons/stub/translations', skipping textdomain
20191211 00:08:34 warning config: add-on 'AEIBN' has no _info.cfg; cannot read version info
20191211 00:08:34 warning config: add-on 'stub' has no _info.cfg; cannot read version info
Checking lua scripts... ok
20191211 00:09:31 warning engine: Addon version data mismatch -- not all local WML has same version of 'AfterEI' addon.
20191211 00:09:34 warning ai/config: side 5: aspect with id=[candidate_action] lacks default config facet!
20191210 23:36:19 warning ai/config: side 5: aspect with id=[candidate_action] lacks default config facet!
I have gone through all instances for side 5, [goal], AI_CA and can't find what sets this off.
20191210 23:37:46 error ai/engine/cpp: side 5 : UNKNOWN aspect[candidate_action*composite_aspect]
This one only recently appeared.
Also these ony appear after I load AfterEI.
The 'AEIBN' and 'stub' warnings are OK, the first is something I'm mucking about with and the second is my little test stub campaign for trying stuff out.
I attach a pdf with screen dumps from the player (not me) that might help?
I'd really rather not bother the player just now as his last PM to me indicated he was very busy indeed.
Any advice on whether these ai issues are significant - and if so how to resolve them - would be appreciated.
If this isn't a bug but something broken in my code, please let me know and apologies for posting this!
Cheers,
Spannerbag
- Attachments
-
- surprise visit bug.pdf
- (3.72 MiB) Downloaded 248 times
- Spannerbag
- Posts: 535
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Possible bug? Update
Hi again,
I've published a workaround so the code I quoted previously is no longer on the add-ons server.
However if you need it I still have the earlier versions saved locally and am happy to send you copies if needed.
Cheers,
Spannerbag
I've published a workaround so the code I quoted previously is no longer on the add-ons server.
However if you need it I still have the earlier versions saved locally and am happy to send you copies if needed.
Cheers,
Spannerbag
Re: Possible bug?
Those AI errors/warnings are produced when the engine encounters an aspect with a name that it does not know. However,
Whether it's serious or not also depends on which CA this is. It won't keep the AI from functioning, but the CA, and therefore its functionality, will be missing from the AI.
[candidate_action]
is not an aspect and is treated differently. Thus, this means that there is an AI configuration somewhere where the code mistakes the [candidate_action]
tag for an aspect. My best guess is that it's probably a setup error (syntax error) for adding a CA. Search for "candidate_action" (and also "CANDIDATE_ACTION" to cover potential macros, if your search is case sensitive) and see if there's anything. Also, could it be in a different add-on (modification) that is active, rather than yours?Whether it's serious or not also depends on which CA this is. It won't keep the AI from functioning, but the CA, and therefore its functionality, will be missing from the AI.
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
- Spannerbag
- Posts: 535
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Possible bug?
Hi mattsc,
After some fiddling around I think I have isolated the issue.
First off as an aside extra_recruit= in side doesn't seem to work (I'm sure it used to) which didn't help in debugging
So I explicitly assign recruit= according to difficulty.
I also tried a number of different combinations of [ai] syntax but that didn't make any difference.
Another wrinkle is the fact that when I'm testing I load a savegame that is the end (linger screen) of the previous scenario.
This is from a previous version of my campaign so when the new scenario loads and the old one ends the log file gets an entry stating:
At least, that's what I'm assuming cases this message. I also assume I can ignore it as the changes to the scenario I'm testing do apply.
Anyways, here's the current version of what I think is the offending code:
Note:
:inspect side 5 gives correct recruitment
:inspect ai gives correct limit (well, seems OK to me) and during testing the ai did (eventually!) recruit a Direwolf Rider.
If I uncomment {AI_CA_POISONING} and do not change anything else then the log changes.
Not sure when log write occurs but the following appear after the orcs are created but before the scenario is quitted:
Could this be because I have 2 CAs in the same [ai] clause? I did try separating them but that didn't seem to do anything...
:inspect of side 5 shows no change to recruit= or ai config.
Before my recent changes the ai might've been consufed because there was a {AI_CA_POISONING} present but no units that could poison... however now the ai can (and does) recruit Direwolf Riders - though none are present initially. That's all I can think of...
All that said, TBH my main concern was the behaviour mismatch between behaviour when Flynn arrived in a
Again, thanks for the reply. I'll probably not publish an update straight away (there are a few other things I need to look at) as the upshot of all this seems to be that the scenario doesn't allow side 5 to recruit Direwolf Riders when it should. I can live with that for now
Cheers!
-- Spannerbag
Thanks for taking the trouble to repy, it's appreciated.mattsc wrote: ↑December 11th, 2019, 2:36 pm Those AI errors/warnings are produced when the engine encounters an aspect with a name that it does not know...
Whether it's serious or not also depends on which CA this is. It won't keep the AI from functioning, but the CA, and therefore its functionality, will be missing from the AI.
After some fiddling around I think I have isolated the issue.
First off as an aside extra_recruit= in side doesn't seem to work (I'm sure it used to) which didn't help in debugging
So I explicitly assign recruit= according to difficulty.
I also tried a number of different combinations of [ai] syntax but that didn't make any difference.
Another wrinkle is the fact that when I'm testing I load a savegame that is the end (linger screen) of the previous scenario.
This is from a previous version of my campaign so when the new scenario loads and the old one ends the log file gets an entry stating:
20191214 12:39:32 warning engine: Addon version data mismatch -- not all local WML has same version of 'AfterEI' addon.
At least, that's what I'm assuming cases this message. I also assume I can ignore it as the changes to the scenario I'm testing do apply.
Anyways, here's the current version of what I think is the offending code:
Code: Select all
[side] # Orcs
side=5
no_leader=yes # Arrive later
controller=ai
team_name=Orcs
user_team_name= _ "Orcs"
#ifdef EASY
recruit=Orcish Grunt, Orcish Warrior, Orcish Archer, Orcish Crossbowman, Orcish Assassin, Orcish Slayer, Wolf Rider, Goblin Knight, Goblin Pillager
#else
recruit=Orcish Grunt, Orcish Warrior, Orcish Archer, Orcish Crossbowman, Orcish Assassin, Orcish Slayer, Wolf Rider, Goblin Knight, Goblin Pillager, Direwolf Rider
#endif
{GOLD 500 700 900}
income=-2
[ai]
passive_leader=no
# {AI_CA_POISONING}
#ifndef EASY
[aspect]
id=recruitment_instructions
[facet]
turns=
[value]
[limit]
type=Direwolf Rider
#ifdef NORMAL
max=1
#endif
#ifdef HARD
max=2
#endif
[/limit]
[/value]
[/facet]
[/aspect]
#endif
[/ai]
[ai] # More aggressive at dusk/night
time_of_day=dusk,first_watch,second_watch
aggression=0.99
caution=0.1
grouping=offensive
[/ai]
[ai] # More cautious at dawn/daytime
time_of_day=dawn,morning,afternoon
aggression=0.75
caution=0.4
grouping=offensive
[/ai]
color=brown
flag=flags/ragged-flag-[1~6].png:150
flag_icon=flags/ragged-flag-icon.png
income=-2
hidden=yes
[/side]
# {AI_CA_POISONING}
:inspect side 5 gives correct recruitment
recruit="Direwolf Rider,Goblin Knight,Goblin Pillager,Orcish Archer,Orcish Assassin,Orcish Crossbowman,Orcish Grunt,Orcish Slayer,Orcish Warrior,Wolf Rider"
:inspect ai gives correct limit (well, seems OK to me) and during testing the ai did (eventually!) recruit a Direwolf Rider.
Code: Select all
recruitment_diversity: 2
recruitment_instructions:
----config begin----
[recruit]
blocker = yes
importance = 0
pattern = yes
total = no
[/recruit]
[limit]
max = 1
type = Direwolf Rider
[/limit]
-----config end-----
If I uncomment {AI_CA_POISONING} and do not change anything else then the log changes.
Not sure when log write occurs but the following appear after the orcs are created but before the scenario is quitted:
20191214 12:59:50 warning ai/config: side 5: aspect with id=[candidate_action] lacks default config facet!
20191214 13:01:56 error ai/engine/cpp: side 5 : UNKNOWN aspect[candidate_action*composite_aspect]
Could this be because I have 2 CAs in the same [ai] clause? I did try separating them but that didn't seem to do anything...
:inspect of side 5 shows no change to recruit= or ai config.
Before my recent changes the ai might've been consufed because there was a {AI_CA_POISONING} present but no units that could poison... however now the ai can (and does) recruit Direwolf Riders - though none are present initially. That's all I can think of...
All that said, TBH my main concern was the behaviour mismatch between behaviour when Flynn arrived in a
side turn
vs die
(or last breath
) event which in the latter case caused a fatal error later on...Again, thanks for the reply. I'll probably not publish an update straight away (there are a few other things I need to look at) as the upshot of all this seems to be that the scenario doesn't allow side 5 to recruit Direwolf Riders when it should. I can live with that for now
Cheers!
-- Spannerbag
Re: Possible bug?
Hi Spannerbag,
I don't know what's going on with the Flynn arrival problem ...
As for the candidate action error, the problem is that that is not how you add a candidate action.
So you either need to include the
I don't know what's going on with the Flynn arrival problem ...
As for the candidate action error, the problem is that that is not how you add a candidate action.
[candidate_action]
tags (such as that macro) do not go directly into [ai]
, but inside [ai][stage]
as shown here.So you either need to include the
[stage]
setup, but then you need to include the entire stage with all the CAs, as at the link above, or for you just adding the CA you can do:{MODIFY_AI_ADD_CANDIDATE_ACTION 5 main_loop {AI_CA_POISONING}}
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
- Spannerbag
- Posts: 535
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Possible bug?
Hi mattsc,
Will update and test later today. As ever many thanks for your time and trouble, it's really appreciated.
... (a few minutes later) ...
Having had a quick look at to mainsteam campaigns I might need to make a lot more changes than I realised to get the ai working as I'd thought. That said, the campaign plays OK as it is... so might just strip out the stuff that may not be working.
I think with AfterEI I have ajob for life...
Cheers!
-- Spannerbag
Aha! Thanks, that's brilliant - I'd completely missed that from the docmentationmattsc wrote: ↑December 14th, 2019, 3:14 pm Hi Spannerbag,
I don't know what's going on with the Flynn arrival problem ...
As for the candidate action error, the problem is that that is not how you add a candidate action.[candidate_action]
tags (such as that macro) do not go directly into[ai]
, but inside[ai][stage]
as shown here.
So you either need to include the[stage]
setup, but then you need to include the entire stage with all the CAs, as at the link above, or for you just adding the CA you can do:
{MODIFY_AI_ADD_CANDIDATE_ACTION 5 main_loop {AI_CA_POISONING}}
Will update and test later today. As ever many thanks for your time and trouble, it's really appreciated.
... (a few minutes later) ...
Having had a quick look at to mainsteam campaigns I might need to make a lot more changes than I realised to get the ai working as I'd thought. That said, the campaign plays OK as it is... so might just strip out the stuff that may not be working.
I think with AfterEI I have ajob for life...
Cheers!
-- Spannerbag