Better MS Scripting Reference: header_operations expanded

Users who are viewing this thread

Total: 2 (members: 0, guests: 2)
Wanted to offer a bit of an explanation for the agent_set_ammo operation. I've fiddle with it for a while in my attempt to save ammunition when a player logs off a multiplayer server. I save the users weapons by storing item ids into my database and then return those values when they log on. I then used agent_set_ammo using the corresponding itemid from the database to set their ammo. The ammo counts also were pulled from the database. However when you have more than one "quiver" of the same type you must add the total value of all in order to set the correct ammo amount. I hope this helps in some way?
 
About:
Code: 
mission_cam_set_animation 
# (mission_cam_set_animation, <anim_id>),
Plays any bone animation from animations.py, taking the coordinates from the first bone in the hierarchy. The name and number of bones does not matter.

Tests:
giphy.gif
V3n2cuK.gif
 
There are some typos in 1.0.1 version:

header_operations expanded v.1.0.1 said:
mission_time_speed_move_to_value = 2004 # (mission_speed_move_to_value, <value_fixed_point>, <duration-in-1/1000-seconds>),
# Changes the speed of time during the mission gradually, within the specified duration period. Speed of time cannot be set to zero or below. Operation only works when cheat mode is enabled.
Click to expand...
"time_" is missing in commented calling syntax, which will cause errors in compiler.

header_operations expanded v.1.0.1 said:
party_remove_prisoners = 1616 # (party_remove_members, <party_id>, <troop_id>, <number>),
# Removes specified number of prisoners from a party. Stores number of actually removed prisoners in reg0.
Click to expand...
there should be "prisoners" instead of "members".

header_operations expanded v.1.0.1 said:
prop_instance_get_scene_prop_kind = 1853 # (prop_instance_get_scene_prop_type, <destination>, <scene_prop_id>),
# Retrieves the scene prop for the specified prop instance.
Click to expand...
there is "type" instead of "kind", which will cause errors in compiler. The comma is missing too

header_operations expanded v.1.0.1 said:
faction_get_color = 1277 # (faction_get_color, <destination>, <faction_id>),

party_get_battle_opponent = 1680 # (party_get_battle_opponent, <destination>, <party_id>),

cur_agent_set_banner_tableau_material = 1986 # (cur_agent_set_banner_tableau_material, <tableau_material_id>),

str_clear = 2319 # (str_clear, <string_register>),

str_store_class_name = 2346 # (str_store_class_name, <stribg_register>, <class_id>),

mission_cam_get_position = 2010 # (mission_cam_get_position, <position_register_no>),

mission_cam_set_position = 2011 # (mission_cam_set_position, <position_register_no>),

mission_cam_animate_to_position = 2012 # (mission_cam_animate_to_position, <position_register_no>, <duration-in-1/1000-seconds>, <value>),

mission_cam_get_aperture = 2013 # (mission_cam_get_aperture, <destination>),

mission_cam_set_aperture = 2014 # (mission_cam_set_aperture, <value>),

mission_cam_animate_to_aperture = 2015 # (mission_cam_animate_to_aperture, <value>, <duration-in-1/1000-seconds>, <value>),

mission_cam_animate_to_position_and_aperture = 2016 # (mission_cam_animate_to_position_and_aperture, <position_register_no>, <value>, <duration-in-1/1000-seconds>, <value>),

mission_cam_set_target_agent = 2017 # (mission_cam_set_target_agent, <agent_id>, <value>),

mission_cam_clear_target_agent = 2018 # (mission_cam_clear_target_agent),

scene_prop_has_agent_on_it = 1801 # (scene_prop_has_agent_on_it, <scene_prop_instance_id>, <agent_id>),

scene_prop_fade_out = 1822 # (scene_prop_fade_out, <scene_prop_id>, <fade_out_time>),

scene_prop_fade_in = 1823 # (scene_prop_fade_in, <scene_prop_id>, <fade_in_time>),

prop_instance_get_animation_target_position = 1863 # (prop_instance_get_animation_target_position, <pos>, <scene_prop_id>),

agent_get_attached_scene_prop = 1756 # (agent_get_attached_scene_prop, <destination>, <agent_id>),

agent_set_attached_scene_prop = 1757 # (agent_set_attached_scene_prop, <agent_id>, <scene_prop_id>),

agent_set_attached_scene_prop_x = 1758 # (agent_set_attached_scene_prop_x, <agent_id>, <value>),

agent_set_attached_scene_prop_y = 1809 # (agent_set_attached_scene_prop_y, <agent_id>, <value>),

agent_set_attached_scene_prop_z = 1759 # (agent_set_attached_scene_prop_z, <agent_id>, <value>),

overlay_get_position = 946 # (overlay_get_position, <position>, <overlay_id>),

overlay_animate_to_color = 932 # (overlay_animate_to_color, <overlay_id>, <duration-in-1/1000-seconds>, <color>),

close_item_details = 971 # (close_item_details),

show_troop_details = 2388 # (show_troop_details, <troop_id>, <position>, <troop_price>),
Click to expand...
Commas are missing.

header_operations expanded v.1.0.1 said:
agent_set_invulnerable_shield = 1725 # (agent_set_invulnerable_shield, <agent_id>, <value>),
# Makes the agent shield invulnerable to any damage (value = 1) or makes him vulnerable again (value = 0).
Click to expand...
"shield" is missing, making it sound like this operation makes invulnerable an agent himself, which is false and may cause confusion.

header_operations expanded v.1.0.1 said:
rebuild_shadow_map = 2393 # (rebuild_shadow_map),
# Version 1.153+. UNTESTED. Effects unknown. Rebuilds shadow map for the current scene. Apparently useful after heavy manipulation with scene props.
Click to expand...
The effects are exactly that - shadows are rebuilt to match prop's new position. When you move the prop and don't use this operation, its shadow will still fall on its old position.

header_operations expanded v.1.0.1 said:
spawn_scene_prop = 1974 # (spawn_scene_prop, <scene_prop_id>),
# Spawns a new scene prop instance of the specified type at the position defined by the last call to (set_spawn_position). Operation was supposed to store the prop_instance_id of the spawned position in reg0, but does not do this at the moment.
Click to expand...
But it does. I tested it and I was able to refer to spawned prop by referring to reg0.

header_operations expanded v.1.0.1 said:
try_for_agents = 12 # (try_for_agents, <destination>, [<position>], [<value>]),
# Runs a cycle, iterating all agents on the scene.
Click to expand...
Turns out this operation has at least 2 optional parameters, which allow to check agents only within specific radius around certain position. Maybe there are optional parameters for other cycles too, I don't know, I have tested only this one, but worth noting in the file nevertheless.
 
Last edited:
The season has opened: (In red the changes to be made)

store_faction_of_troop = 2173 # (store_faction_of_troop, <destination>, <troop_id>),
# Alternative spelling of the above operation.
Click to expand...
script_game_get_faction_notze script_game_get_faction_note
Click to expand...
str_store_string_reg = 2321 # (str_store_string_reg, <string_register>, <string_no>),
# Copies the contents of one string register from another.
Click to expand...
question_box = 1121 # (question_box, <string_id>, [<yes_string_id>], [<no_string_id>]),
# Displays a popup window with the text of the question and two buttons (Yes and No by default, but can be overridden). When the player selects one of possible responses, a ti_question_answered trigger will be executed.
Click to expand...
mission_tpl_entry_set_override_flags = 1940 # (mission_tpl_entry_set_override_flags, <mission_template_id>, <entry_no>, <value>),
# Allows modder to use a different set of equipment override flags (see af_* constants in header_mission_templates.py) for the selected entry point.
mission_tpl_entry_clear_override_items = 1941 # (mission_tpl_entry_clear_override_items, <mission_template_id>, <entry_no>),
# Clears the list of override equipment provided by the entry point definition in module_mission_templates.py.
mission_tpl_entry_add_override_item = 1942 # (mission_tpl_entry_add_override_item, <mission_template_id>, <entry_no>, <item_kind_id>),
# Specified item will be added to any agent spawning on specified entry point.
Click to expand...
player_set_team_no = 403 # (player_set_team_no, <player_id>, <team_id>),
# Assigns a player to the specified team.
Click to expand...
player_set_troop_id = 405 # (player_set_troop_id, <player_id>, <troop_id>),
# Assigns the selected troop reference to a player.
Click to expand...
multiplayer_set_my_troop = 413 # (multiplayer_set_my_troop, <destination>),
# Client operation. Selects a new troop for the player.
Click to expand...
conversation_screen_is_active = 42 # (conversation_screen_is_active),
# Checks that the player is currently in dialogue with some agent. Can only be used in triggers of module_mission_templates.py file.
Click to expand...

EDIT: added changes
party_set_extra_icon = 1682 # (party_set_extra_icon, <party_id>, <map_icon_id>, <vertical_offset_fixed_point>, <up_down_frequency_fixed_point>, <rotate_frequency_fixed_point>, <fade_in_out_frequency_fixed_point>),
# Adds or removes an extra map icon to a party, possibly with some animations. Use 0 as map_icon_id to remove extra icon.
Click to expand...
 
Last edited:
Wolfynator said:
Can this be used on the latest version of Warband?
Click to expand...
This is the native 'header_operations' but organized in categories and with extended and improved documentation of what each operation is supposed to do. (read carefully the OP)
Note that the revision only covers up to v.1.166...? of Warband, some operations have been added later that are not included.
Personally I only use it as a reference... although you can update it and use it, why not...
Wolfynator said:
is it necessary to replace the process_operations.py as well?
Click to expand...
Yes, a new list of operations would need to be referenced (depth_operations) in case you want to use it, otherwise, no. But the list adds 2 more operations to be checked by the compiler, in my opinion, forgotten by TW in the last updates.
With all this in mind, the decision is yours.
 
Dj_FRedy said:
Yes, a new list of operations would need to be referenced (depth_operations) in case you want to use it, otherwise, no. But the list adds 2 more operations to be checked by the compiler, in my opinion, forgotten by TW in the last updates.
With all this in mind, the decision is yours.
Click to expand...
Do you mean that there are two operations which are not in process_operations of the latest Native module system which are inside the file here?
 
I mean that if you use Lav's 'header_operations' you can add a new list created by Lav, namely 'depth_operations', to the native 'process_operations', that's why 'process_operations' is attached with the download, because this list is already referenced. The list adds two more operations to check by the compiler that it does not have the native 'compiler'.
Python: 
depth_operations = [try_begin,
                    try_for_range,
                    try_for_range_backwards,
                    try_for_parties,
                    try_for_agents,
                    try_for_prop_instances,
                    try_for_players
                    ]
Python: 
    # if (opcode in [try_begin,
                   # try_for_range,
                   # try_for_range_backwards,
                   # try_for_parties,
                   # try_for_agents]):
    ### for new operations cycle (try_for_prop_instances and try_for_players) in header_operations.py +Dj_FRedy
    if (opcode in depth_operations):
    ### for new operations cycle
It can also be added directly to the compiler... Lav likes lists xD.
 
Last edited:
Yep, this:
New 1.165 operations (try_for_prop_instances) and (try_for_players) are now correctly identified as "depth-increasing" operations (this affects compiler checks for unsafe can-fail operations and extra/missing (try_end)'s).
Click to expand...
Connected? Well, it's the same author, and he uses his modifications. This is part of his work, separated for better distribution, I guess.
 
Last edited:
Dj_FRedy said:
This is the native 'header_operations' but organized in categories and with extended and improved documentation of what each operation is supposed to do. (read carefully the OP)
Note that the revision only covers up to v.1.166...? of Warband, some operations have been added later that are not included.
Personally I only use it as a reference... although you can update it and use it, why not...
Click to expand...
Oh that makes more sense now. Thanks for clearing it up.
 
Python: 
agent_get_speed                          = 1689  # (agent_get_speed, <position>, <agent_id>),
                                                 # Retrieves agent speed to (X,Y) coordinates of the position register.
                                                 # Speed is in decimeters/second in local space to the agent with -X being left, +X right, -Y backwards, and +Y being forwards.
 
It doesn't make life easier. Now I have 3 header_operations from different guys and need to merge them all.

I started a wiki page where I can also put some code samples. The latest updates are there. So I will not update my file unless I will learn how to parse wiki page. https://mbcommands.fandom.com/wiki/Operators

SupaNinjaMan said:
Python: 
agent_get_speed                          = 1689  # (agent_get_speed, <position>, <agent_id>),
                                                 # Retrieves agent speed to (X,Y) coordinates of the position register.
                                                 # Speed is in decimeters/second in local space to the agent with -X being left, +X right, -Y backwards, and +Y being forwards.
Click to expand...

Position is always fixed_point coordinates. I have debugged speed. You can see result on wiki.
 
Vetrogor said:
It doesn't make life easier. Now I have 3 header_operations from different guys and need to merge them all.
Click to expand...
I already merged all available files. It might only be that you have updated some explanations by yourself.
Vetrogor said:
I started a wiki page where I can also put some code samples. The latest updates are there. So I will not update my file unless I will learn how to parse wiki page. https://mbcommands.fandom.com/wiki/Operators
Click to expand...
I am personally not happy with wiki pages because they always, really always, proved to be not available anymore after a few years. Additionally there is no easy way now to compare the total file with the one we have ourselves too see which explanations have been updated. It's up to you though.
 
Last edited:
I integrated the new informations of yours into the file.

Some little stuff is updated in regard of informations. You also forgot about the operation allow_ironman
Code: 
allow_ironman                         = 988   # (allow_ironman, <value>),
                                              # 1 = allow, 0 = disallow. Used on new games to disable realistic mode.

I have some little contradicting explanation at these operations. Your explanations first:
Code: 
omit_key_once = 77 (omit_key_once, <key_code>),  #Forces the game to ignore default bound action for the specified key on next press. Some keys can't be omited.
clear_omitted_keys = 78    (clear_omitted_keys), #Clear all omitted keys.
The current explanations:
Code: 
omit_key_once                   = 77      # (omit_key_once, <key_code>),
                                        # Forces the game to ignore default bound action for the specified game key on current game frame.
clear_omitted_keys              = 78      # (clear_omitted_keys),
                                        # Commonly called when exiting from a presentation which made any calls to (omit_key_once). However the effects of those calls disappear by the next frame, so apparently usage of this operation is not necessary. It is still recommended to be on the safe side though.
Are you sure that it is on the next press and and not on the current game frame?
 
You must log in or register to reply here.

Similar threads

Swyter
OpenBRF Redux — A de-rusted, bug-fixed version of the tool
Replies
10
Views
383
Nanobubbles.
gsanders
Phantasy Calradia - 2024 reboot
Replies
8
Views
301
gsanders
gsanders
  • Locked
Map Dispute [Appeal Request]
Replies
3
Views
503
Lucon
Lucon
Back
Top Bottom