trouble with CALL_FUNCTION
Moderator: Forum Moderators
Forum rules
- Please use [code] BBCode tags in your posts for embedding WML snippets.
- To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
trouble with CALL_FUNCTION
When I use CALL_FUNCTION in a side turn event, I see a bunch of errors and warnings in my xterm.
In a side turn event, I wrote
The only 'anl filter recruits' event is
During each side turn, my xterm shows
Despite these errors, the function call seems to work. Also, these errors only happen if I use CALL_FUNCTION in a side turn event; there are no errors if I call the same function from a menu item. CALL_FUNCTION is a core macro in data/core/macros/event-utils.cfg; you can read my code (except for the three WARNING lines, which I added just now) in utils/auto_working.cfg line 154 and recruits.cfg line 16.
I would like to prevent these errors. Is it wrong to use CALL_FUNCTION in a side turn event? Why do I only see errors about $unit, and not about $second_unit? What should I do?
In a side turn event, I wrote
Spoiler:
Spoiler:
Spoiler:
I would like to prevent these errors. Is it wrong to use CALL_FUNCTION in a side turn event? Why do I only see errors about $unit, and not about $second_unit? What should I do?
--Kernigh http://www.wesnoth.org/wiki/User:Kernigh
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: trouble with CALL_FUNCTION
Are you using the string unit as a name for a variable ? One shouldn't do that, since the engine believes a variable named unit to be the automatically stored special variable with this name which is available in certain event types (but not in side turn events).
Probably similar for other automatically stored variables. This is not mentioned in the wiki IIRC.
Probably similar for other automatically stored variables. This is not mentioned in the wiki IIRC.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: trouble with CALL_FUNCTION
No, I believe that my side turn event never uses $unit as a variable. Some other events (or menu items) are using $unit to access the auto-stored unit, but my side turn event never uses $unit.Anonymissimus wrote:Are you using the string unit as a name for a variable ?
To be sure, I added a {CLEAR_VARIABLE unit}. I wanted to clear any $unit variable that I might accidentally have. I changed the function call to
Code: Select all
{CLEAR_VARIABLE unit}
{WARNING "-- before function"}
{CALL_FUNCTION (anl filter recruits) (
variable=t.pick
option=warfare
)}
{WARNING "-- after function"}
Code: Select all
20120611 20:08:05 error engine: failed to auto-store $unit at (-999,-999)
20120611 20:08:05 warning wml: -- before function
# same errors as before...
20120611 20:08:05 warning wml: ---- entered function
20120611 20:08:05 warning wml: -- after function
My next idea was to create a $unit variable. Maybe the engine would not auto-store $unit if I already had one.
Code: Select all
[set_variables]
name=unit
[literal]
[/literal]
[/set_variables]
{WARNING "-- before function"}
{CALL_FUNCTION (anl filter recruits) (
variable=t.pick
option=warfare
)}
{WARNING "-- after function"}
Spoiler:
--Kernigh http://www.wesnoth.org/wiki/User:Kernigh
Re: trouble with CALL_FUNCTION
This is part of the definition of CALL_FUNCTION:
The side turn event has no $x1,$y1 location, thus it attempts to auto-store $unit from the null location (-999,-999), and there is no unit in that location.
While it is safe to disregard that "error", CALL_FUNCTION may need to be modified to be rid of it.
Otherwise, the only workaround I can think of would be firing an event from side turn with a valid [primary_unit] specified, then using CALL_FUNCTION from that.
Code: Select all
x,y=$unit.x,$unit.y
While it is safe to disregard that "error", CALL_FUNCTION may need to be modified to be rid of it.
Otherwise, the only workaround I can think of would be firing an event from side turn with a valid [primary_unit] specified, then using CALL_FUNCTION from that.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Re: trouble with CALL_FUNCTION
Thank you! This prevented the error messages. I renamed my 'side turn' event to 'anl side turn', and then wroteSapient wrote:... firing an event from side turn with a valid [primary_unit] specified, then using CALL_FUNCTION from that.
Code: Select all
[event]
name=side turn
first_time_only=no
# Inside a side turn event, CALL_FUNCTION would give a pile of
# errors and warnings, starting with:
# error engine: failed to auto-store $unit at (-999,-999)
#
# This "error" is harmless but annoying, and happens because
# CALL_FUNCTION wants a primary unit. To prevent this "error",
# here is a trampoline to attach a primary unit.
[fire_event]
name=anl side turn
[primary_unit]
canrecruit=yes
[/primary_unit]
[/fire_event]
[/event]
I can now guess the cause of the original errors. I had 8 pairs of errors; each pair contains 2 auto-store errors, 1 unit.x warning and 1 unit.y warning. The "x,y=$unit.x,$unit.y" quoted by Sapient is part of a StandardUnitFilter. My map had 8 units. Wesnoth used the filter 8 times, and accessed $unit 16 times. As Anonymissimus said, "the engine believes a variable named unit to be the automatically stored special variable", so Wesnoth tried 16 times to find the auto-stored $unit. This seems to explain all 16 auto-store errors, all 8 unit.x warnings and all 8 unit.y warnings.
In the definition for CALL_FUNCTION, I noticed something that I missed before.
Code: Select all
[fire_event]
name={EVENT_NAME}
[primary_unit]
x,y=$unit.x,$unit.y
[/primary_unit]
[second_unit]
x,y=$second_unit.x,$second_unit.y
[/second_unit]
[/fire_event]
I had believed that CALL_FUNCTION handled $unit and $second_unit the same way. I was confused about why I saw 16 errors about $unit but none about $second_unit. Because of [second_unit] rather than [secondary_unit], CALL_FUNCTION never uses $second_unit!
--Kernigh http://www.wesnoth.org/wiki/User:Kernigh
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: trouble with CALL_FUNCTION
Note that in your case it is not relevant, since the variable named unit actually is or should be this automatically stored variable. So my guess in my first post above was wrong (but it was a possibility).Kernigh wrote:As Anonymissimus said, "the engine believes a variable named unit to be the automatically stored special variable", so Wesnoth tried 16 times to find the auto-stored $unit. This seems to explain all 16 auto-store errors, all 8 unit.x warnings and all 8 unit.y warnings.
EDIT
It should be fixed now, as well as the spurious stderr messages.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign