trouble with CALL_FUNCTION

The place to post your WML questions and answers.

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.
Post Reply
Kernigh
Posts: 107
Joined: February 13th, 2007, 10:21 pm
Location: United States
Contact:
Contact Kernigh

trouble with CALL_FUNCTION

Post by Kernigh »

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
Spoiler:
The only 'anl filter recruits' event is
Spoiler:
During each side turn, my xterm shows
Spoiler:
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?
Top
Anonymissimus
Inactive Developer
Posts: 2461
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: trouble with CALL_FUNCTION

Post by Anonymissimus »

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.
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
Top
Kernigh
Posts: 107
Joined: February 13th, 2007, 10:21 pm
Location: United States
Contact:
Contact Kernigh

Re: trouble with CALL_FUNCTION

Post by Kernigh »

Anonymissimus wrote:Are you using the string unit as a name for a variable ?
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.

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"}
This caused a new error:

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
Yes, the {CLEAR_VARIABLE unit} added a new "error engine: failed to auto-store $unit at (-999,-999)". I guess that {CLEAR_VARIABLE unit} causes the engine to auto-store a unit just so I can clear said unit?

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"}
This did not remove all the errors:
Spoiler:
It seems that [set_variables]name=unit caused the engine to auto-store $unit, and then CALL_FUNCTION caused the engine to auto-store $unit (16 times) despite my already having a fake $unit.
Top
User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:
Contact Sapient

Re: trouble with CALL_FUNCTION

Post by Sapient »

This is part of the definition of CALL_FUNCTION:

Code: Select all

            x,y=$unit.x,$unit.y
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.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Top
Kernigh
Posts: 107
Joined: February 13th, 2007, 10:21 pm
Location: United States
Contact:
Contact Kernigh

Re: trouble with CALL_FUNCTION

Post by Kernigh »

Sapient wrote:... firing an event from side turn with a valid [primary_unit] specified, then using CALL_FUNCTION from that.
Thank you! This prevented the error messages. I renamed my 'side turn' event to 'anl side turn', and then wrote

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]
This solves the problem in my original post. The "error" is now gone, and will no longer bury other errors in my xterm that I might want to see.

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]
There is no [fire_event][second_unit] subtag! The correct tag would be [fire_event][secondary_unit]. I now report this as bug #19805 [Gna.org].

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!
Top
Anonymissimus
Inactive Developer
Posts: 2461
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: trouble with CALL_FUNCTION

Post by Anonymissimus »

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.
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).

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
Top
Post Reply

Return to “WML Workshop”