Clarifying Module System Operations

Users who are viewing this thread

Thanks!

I intend to release a new version, so please keep those errors coming, the more I know of, the more I'll fix. :smile:
 
Anybody know the mechanism of this operation below?
store_num_parties_destroyed_by_player = 2302 # (store_num_parties_destroyed_by_player,<destination>,<party_template_id>),

I don't ask what the operation do and what for. I ask where the data 's actually being stored and when the data's actually modified by the game engine.
I did overide the way the enemy parties destroyed from world map and clean them up manually from world map via script, and it seems that prevent the game acknowledge about the parties destroyed by player.
The operation itself is  used by native only for dealing with looters and dealing with troublesome bandits quests. I can immitate the operation by slot based script but it's always be good to use native operation if it's availabe.
 
Well, if I track the progress of looters quest, I get the following sequence of events:

1. In dialog with looters, (encounter_attack) is called to initiate a common battle.
2. After the battle is won, (set_mission_result,1) and (finish_mission,1) are called.

Everything else is not mission-specific and shouldn't affect the counter of destroyed parties.

So execution of these three operations is apparently enough to increase the counter by 1. Maybe some of these operations are not actually necessary for that, this needs further testing.
 
Somehow, I broke the mechanism.
Here's my battle sequence :
1. encounter attack, starting the battle
2. in the battle I use the timer to measure how long the battle is.
3. ending the battle 's not changed. set_mission_result and finish_mission 's untouched
4. after displaying battle debrief menu, clicking continues will push the main party to rest for scpecific time based on step 2 measurement result. I save the parties encountered ids to global variables.
5. In the end of resting, it calls start_encounter with the parties Id I saved on step 4.
6. The auto encountered will recall simple_encounter menu again but not being considered as new encounter.
7. If enemy parties active member is zero then jump to total victory menus.
8. I have to clean up the world map manually for at the end of the battle, parties with 0 members some how 's not automatically destroyed. I think this step that failed the counter.
 
dunde said:
4. after displaying battle debrief menu, clicking continues will push the main party to rest for scpecific time based on step 2 measurement result. I save the parties encountered ids to global variables.
5. In the end of resting, it calls start_encounter with the parties Id I saved on step 4.
6. The auto encountered will recall simple_encounter menu again but not being considered as new encounter.
My thoughts are as follows. While this is not considered to be a new encounter by MS script, this is still considered a completely new encounter by the game engine. In other words, from the engine's point of view player does not destroy the enemy party during the first encounter, and then during the second encounter player does not destroy it again because it's removed from the map manually.

Also, I forgot about menus when I wrote previous message. Correct sequence is:

1. In dialog with looters, (encounter_attack) is called to initiate a common battle.
2. In game menu before attack, (set_party_battle_mode) is called.
3. During the mission, after the battle is won, (set_mission_result,1) and (finish_mission,1) are called.
4. In game menu after attack, (end_current_battle) and (leave_encounter) are called.

By the way, does the game recognize player destroying a party if that party was destroyed with autocalc? If it does, then mission operations actually have no effect on this.
 
All right, I managed to destroy a party and increase game internal counter with the following code. Apparently, this is perfectly enough.

Code:
    (0.0, 0, 0,
        [
            (key_clicked, key_e),
        ],
        [
            (start_encounter, "$g_research_party"),
        ],
    ),
    (0.0, 0, 0,
        [
            (key_clicked, key_n),
        ],
        [
            (store_num_parties_destroyed_by_player, reg0, "pt_research"),
            (display_message, "@Counter: {reg0}."),
        ],
    ),

Code:
(eq, "$g_encountered_party", "$g_research_party"),
(jump_to_menu, "mnu_research"),
# Prevent rest of the code from executing

Code:
    ("research", mnf_disable_all_keys,
        "You kicked their ass!",
        "none",
        [
            (party_clear, "$g_research_party"),
        ],
        [
            ("doit", [], "Leave.",
                [
                    (leave_encounter),
                    (change_screen_return),
                ]
            ),
        ],
    ),
Research party was automatically removed from the map, and the counter increased. So the rule is:

In encounter context, if (leave_encounter) is called and the encountered party has zero members, it is automatically removed from the map and the internal counter for the number of parties with corresponding party_template destroyed by player is increased by one.

There is absolutely no need to enter mission mode, set party battle mode, end current battle, deal damage to party with inflict_casualties et cetera. All that matters is context and party size at the end of encounter.

UPDATE. Moving all game menu code to first section like this:
Code:
    ("research", mnf_disable_all_keys,
        "You will never see this menu!",
        "none",
        [
            (party_clear, "$g_research_party"),
            (leave_encounter),
            (change_screen_return),
        ],
        [
            ("you_will_never_see_it", [], "Leave.", []),
        ],
    ),
Allowed me to destroy the party instantly by clicking the "E" key, without showing any menus or whatever, while still registering the destroyed party for player. You just hit the key, research party disappears from the map, and the counter is increased. :smile:

At the same time, all attempts to put this code entirely in script_game_event_party_encounter resulted in CTD. Apparently Warband does not like it when you leave the encounter from this script. So you must pass control outside (usually to some menu but other screens will probably work too) and then destroy the party and leave the encounter.
 
Thanks for the test. It make me clear where the missing link I had. It seems that for making the enemy party's automatically removed from wolrd map and counted as party destroyed by player if we encounter them and then their nember's decreased til zero. In my squence of time shifting battle, I did make the encounter every end of round, but after the last round we will encounter empty party (if we win the battle). That's why the game didnt remove the party, becaouse the party's already zero member when the last forced encounter occured.
I think I must give them a dummy troops before last encounter.
 
Code:
player_set_gold                              =  408  # (player_set_gold, <player_id>, <value>, <max_value>), #set max_value to 0 if no limit is wanted

in  module script some times last argument is ommited:
Code:
line: 5493 Not enougha args player_set_gold ":dead_agent_player_id", ":player_gold"
line: 7890 Not enougha args player_set_gold ":player_no", ":initial_gold"
line: 7917 Not enougha args player_set_gold ":player_no", ":initial_gold"
Can  <max_value> be an optional argument or it is bug in module system?
 
Code:
set_spawn_effector_scene_prop_id             =  427  # (set_spawn_effector_scene_prop_id <scene_prop_id>)

used in code with 2 arguments:
Code:
line: 12226 Too many args set_spawn_effector_scene_prop_id  ":assigned_flag_count" ":flag_of_team_1" 
line: 12236 Too many args set_spawn_effector_scene_prop_id  ":assigned_flag_count" ":flag_of_team_2" 
line: 12240 Too many args set_spawn_effector_scene_prop_id  ":assigned_flag_count" -1
 
Code:
cur_agent_set_banner_tableau_material            = 1986  # (cur_agent_set_banner_tableau_material, <tableau_material_id>)

only one example in module scripts:
Code:
(assign, reg0, ":banner_mesh"),
(cur_agent_set_banner_tableau_material, ":tableau_no", reg0),

may be agent id is optional?
 
If operation is called in Native with less arguments and no errors are thrown, then the last argument is indeed optional.

Re: cur_agent_set_banner_tableau_material, seems it's call syntax is described incorrectly, will check this out. Same with set_spawn_effector_scene_prop_id.

It seems that with this amount of bugs I'll have to release next version much sooner than I expected. :smile:

Great thanks for your research, that really helps!
 
@Lav and everyone that's helped... I found that document very useful and reading through this thread has been quite beneficial as well.

Thanks.
 
A question to fellow modders: has anyone tested the new operations in the upcoming 1.161 patch?

I'm currently interested in (item_get_*) operations - they're listed to only take item_id as parameter, but can they perchance accept item modifier as well to provide the resulting value?

Facecode operations are also interesting as they might rejuvenate the idea of dynamic aristocracy. :smile:

Unfortunately my Warband installation is not from Steam, so I'm currently stuck until the patch becomes available from Taleworlds directly. :sad:
 
I'm personally interested in get/set_battle_size, and whether or not they'd work in all situations. And those face key/skin colour/hair operations are looking juicy as well. For once, things like sleeves and non-bald helmets will be feasible. I'll probably try them out in the near future.
 
The new mesh and material ops can also save a lot of item tuples, but what I'm liking most is the (though limited) ability to retrieve numbers from a string or vice-versa, which comes with the new facecode ops.
 
Back
Top Bottom