More odd issues...

[jik]

ok, so I have been having this problem with the music, now it seems that my mission end trigger is miss firing...  Here it is:

Spoiler

###Round Ending Trigger
(10, 0, ti_once,
[
(ge,"$zombies_spawned","$max_zombies"),                    ##Make sure the mission has started
            (this_or_next|main_hero_fallen),
            (num_active_teams_le, 1),
],
[
(try_begin),
(neg|main_hero_fallen), ##You have defeated this wave of zombies!
(assign,reg23,"$searched"),
(call_script,"script_cf_search_find"), ##works out what serachers found
(call_script,"script_cf_search_end",), ##calculates XP for fighters
(jump_to_menu,"mnu_search_more"),
(finish_mission),
(else_try), ##You have fallen in battle...
(dialog_box,"@The Zombies have overcome your party...","@Player Defeated"),
(jump_to_menu,"mnu_player_defeat"),
(finish_mission),
(try_end),
]
),

pretty simple.  Now the oddest thing.  It worked fine before, but all of a sudden, when I finish the mission (all the zombies are dead and the player is still alive) the 2 scripts (search_find and search_end) run, but it seems that the game then jumps to the player_defeat menu.  No too sure how this can be happening...  could it be something with the menus:

Spoiler

("search_more",0,
###Use reg20,21 and 22 to store food, wood and steel found.  Script it at the end of a successful mission
"After fighting off the mob of zombies, you contemplate how safe it is to keep searching.^You have gathered {reg20} food, {reg21} Wood, and {reg22} Steel!^You have currently searched for {reg23} hours.",
"none",[],          ##Assign searched hours to reg23 at the successful end of the mission
[##option Choices
("search_1",[(stop_all_sounds,1)],"Search the city for an additional hour",
[
(set_jump_mission, "mt_city_zombies"),
(reset_visitors),
(modify_visitors_at_site, "scn_zombie_town"),
(set_visitor, 0, "trp_player"),
(call_script,"script_search_party","p_main_party",40),    ##bring in up to 40 of the fighting type units into the fight
(jump_to_scene, "scn_zombie_town"),
(change_screen_mission),
]
),
("back",[(eq,1,1)],"Leave with your spoils.",
[
(change_screen_return),
]
),


]
),


("zombie_run",0,
"Unable to fight off the zombie onslaught, you and your men are chased from the city.^You soon loose the slow moving mob, but also any spoils you were gathering.","none",[],
[##option Choices
("back",[(eq,1,1)],"Back to the map.",
[
(change_screen_return),
]
),


]
),

("player_defeat",0,
"Unable to fight off the zombie onslaught, you and your men are overcome.^Maybe being a zombie won't be soo bad....^(Normally this would be the end...)","none",[],
[##option Choices
("back",[(eq,1,1)],"Back to the map.",
[
(change_screen_return),
]
),
]
),

It specifically goes to the defeat menu at the bottom.  I'm confused...

 

[foxyman]

I noticed that the search_end is marked with "cf", so it can fail. Maybe you should go through it for some conditioning that halts the script.

 

[Zsar]

If this behaved like a nice normal imperative language, this should not be an issue.
Or does call_script return a boolean value (false) if the script to be executed fails? This could be an explanation, since the first conditional block was evaluated as "true && false" -> false; and the interpreter jumped into the second block.

Like this:

(neg|main_hero_fallen), # true
(assign, reg23, "$searched"),
(call_script, "script_cf_search_find"), # script fails, thus false
# try-block broken
(dialog_box, "@The Zombies have overcome your party...","@Player Defeated"),
(jump_to_menu,"mnu_player_defeat"),
(finish_mission),

But it did not show the dialog box, or did it? And since it did not, this can hardly be what happens.

... May we see the two scripts, too?

And did you check if the trigger does indeed fire exactly one time per mission?

 

[foxyman]

OK. I've tried some cf_ scripts in my own code. They act pretty much like the (eq, ) / (neq, ) thing. That is, if the script fails, it halts the current branch calling the script, and can be caught by (else_try). So I'm pretty sure that there's something inside script_cf_search_end that halts this branch.

 

[jik]

OK. I've tried some cf_ scripts in my own code. They act pretty much like the (eq, ) / (neq, ) thing. That is, if the script fails, it halts the current branch calling the script, and can be caught by (else_try). So I'm pretty sure that there's something inside script_cf_search_end that halts this branch.

ok, maybe that's the issue. 

LordZsar1, the scripts are in the second spoiler.  I have them able to fail since I've always learned not to waste programming power.  If the whole script doesn't need to be run then I exit out of it.  I guess I can change that by adding an overall try block around it and have that fail out.  Thanks for the info.  This is an oddity that I will add to the tutorial update FAQ section.  Thanks for your help.

 

[Zsar]

I have them able to fail since I've always learned not to waste programming power.

Reads as if I met a brother in mind here. ^^

[...] the scripts are in the second spoiler.

I can, however not attempt to find the script "cf_search_end". Also, those things in the second spoiler are, if the syntax does not fool me, game_menus, not scripts. (Both kinds are code, sure, but should they not be located in different module files and thus mark different prefixes?) So I thought that you had extra scripts in your module_scripts.py.
... Wait a moment... I should first check my own eyes, then mayhaps decide to believe in the word of others - there is no cf_search_collect either in that spoiler. So I was indeed right with my initial thoughts, was I not? game_menus, not scripts. No scripts at all visible there.
Well, since the problem is already solved, who cares now.

I guess I can change that by adding an overall try block around it and have that fail out.

Well, if you have to add those tries, why not just around the script calls instead?
(But I have to wonder, and that is probably the single whole sense of this post:
Should these scripts not really never fail? Since the player did just fight and now has to get some ressources, has he not to?)

 

[jik]

opps..  Sorry, you are right, those are the menus.

There are various reasons to terminate a block of code (module/script/other).  My problem was that I started to get lazy and make all my scripts cf, just in case.  My latest script (third level down in calls) actually could fail.  Basically I was testing if there are top tier troops, if there were I would, if there was space, upgrade them to a hero.  There are a few other tests that are done, and 1 or 2 failed out the script.  Since all the scripts were cf, the fail cascaded down to the bottom.  Well, a good learning experience.  The level 3 script can still fail, but the others won't.

In this case, there are several tests that I don't want to place in different areas around when this script is called.  My fail outs were just simple checks that variables were changed, so it was easy to fix from something like

...(code)
(neq,":check",0),
(code)....

to

...(code)
(try_begin),
    (neq,":check",0),
    (code)...
(try)end),
(code)...