Better MS Scripting Reference: header_operations expanded

Users who are viewing this thread

not wanting to necropost this but since you're keeping the main post updated I don't mind as much;
Code:
create_check_box_overlay                          =  918  # (create_check_box_overlay, <destination>),
                                                          # Creates a checkbox overlay. Returns checkbox overlay_id.
this operation is missing the last two values, which are meshes for ticked and unticked checkbox, if you use it just like that the checkboxes won't work.
i.e:
Code:
(create_check_box_overlay, "$g_presentation_obj_admin_panel_5", "mesh_checkbox_off", "mesh_checkbox_on"),

also, since you don't have documentation on most multiplayer operations:
Code:
server_get_renaming_server_allowed           =  475  # (server_get_renaming_server_allowed, <destination>), #0-1
server_get_changing_game_type_allowed        =  476  # (server_get_changing_game_type_allowed, <destination>), #0-1
both of these get the values for dedicated servers which have commands to run on the console to (dis)allowing them
Code:
set_spawn_effector_scene_prop_kind           =  426  # (set_spawn_effector_scene_prop_kind <team_no> <scene_prop_kind_no>)
set_spawn_effector_scene_prop_id             =  427  # (set_spawn_effector_scene_prop_id <scene_prop_id>)
this two are used in capture the flag and similar game modes to make players of a certain team tend to spawn nearer to those scene props
Code:
player_control_agent                         =  421  # (player_control_agent, <player_id>, <agent_id>),
this is used to make the player respawn when he dies as a bot, so he controls an active agent. this will also make the face keys and banner of the agent change to correspond to the player's face and banner
Code:
player_spawn_new_agent                       =  409  # (player_spawn_new_agent, <player_id>, <entry_point>),
is basically a combination of spawn_agent and player_control_agent afaik.
Code:
get_max_players                              =  400  # (get_max_players, <destination>),
never tested to check but I think it always return a constant but is not deprecated because taleworlds increase this limit in patches from time to time.
Code:
multiplayer_send_message_to_server           =  388  # (multiplayer_send_int_to_server, <message_type>),
multiplayer_send_int_to_server               =  389  # (multiplayer_send_int_to_server, <message_type>, <value>),
multiplayer_send_2_int_to_server             =  390  # (multiplayer_send_2_int_to_server, <message_type>, <value>, <value>),
multiplayer_send_3_int_to_server             =  391  # (multiplayer_send_3_int_to_server, <message_type>, <value>, <value>, <value>),
multiplayer_send_4_int_to_server             =  392  # (multiplayer_send_4_int_to_server, <message_type>, <value>, <value>, <value>, <value>),
multiplayer_send_string_to_server            =  393  # (multiplayer_send_string_to_server, <message_type>, <string_id>),
multiplayer_send_message_to_player           =  394  # (multiplayer_send_message_to_player, <player_id>, <message_type>),
multiplayer_send_int_to_player               =  395  # (multiplayer_send_int_to_player, <player_id>, <message_type>, <value>),
multiplayer_send_2_int_to_player             =  396  # (multiplayer_send_2_int_to_player, <player_id>, <message_type>, <value>, <value>),
multiplayer_send_3_int_to_player             =  397  # (multiplayer_send_3_int_to_player, <player_id>, <message_type>, <value>, <value>, <value>),
multiplayer_send_4_int_to_player             =  398  # (multiplayer_send_4_int_to_player, <player_id>, <message_type>, <value>, <value>, <value>, <value>),
multiplayer_send_string_to_player            =  399  # (multiplayer_send_string_to_player, <player_id>, <message_type>, <string_id>),
all of them are handled by this script:
Code:
	#script_game_receive_network_message
	# This script is called from the game engine when a new network message is received.
	# INPUT: arg1 = player_no, arg2 = event_type, arg3 = value, arg4 = value_2, arg5 = value_3, arg6 = value_4
as for strings, the input is s0
Code:
send_message_to_url                          =  380  # (send_message_to_url, <string_id>, <encode_url>), #result will be returned to script_game_receive_url_response
this one is also related to a script, it will send the string with information to the specified url and any responses will be handled by script_game_receive_url_response:
Code:
	#script_game_receive_url_response
	#response format should be like this:
	#  [a number or a string]|[another number or a string]|[yet another number or a string] ...
	# here is an example response:
	# 12|Player|100|another string|142|323542|34454|yet another string
	# INPUT: arg1 = num_integers, arg2 = num_strings
	# reg0, reg1, reg2, ... up to 128 registers contain the integer values
	# s0, s1, s2, ... up to 128 strings contain the string values
Code:
player_is_busy_with_menus                    =  438  # (player_is_busy_with_menus, <player_id>),
this one is used when a player presses a hotkey like TAB or ESC to check if he doesn't have any kind of presentation open, however, it works strangely and is almost always acompannied by some sort of (neg|presentation_is_active, "prst"), in native
Code:
multiplayer_make_everyone_enemy              =  420  # (multiplayer_make_everyone_enemy),
this is used in deathmatch mode to ignore teams and make everyone able to hit everyone regardless of friendly fire and also remove the little circles with the banners on top of teammate's head
Code:
player_set_is_admin                          =  429  # (player_set_is_admin, <player_id>, <value>), #value is 0 or 1
this will make the selected player an admin(or not) untill he relogs


all the others are pretty self-explanatory I think
 
Ok, most operations have been checked and tested. Operation (mouse_get_world_projection) only works in mission time it seems, which is a shame (but still extremely useful).

The following issues have been discovered so far.

1. Operation (cast_ray) is not behaving according to official comments. It is not a can-fail operation, at least I never managed to make it fail. Seems the operation returns -1 when there's no hit instead of failing. What's worse however, is the persistent failure of the operation to raycast main camera's line of sight. Values returned by the operation seem arbitrary and do not seem to be affected by where the camera is pointing. I didn't check the coordinates though - maybe it's only instance_id that's incorrect, in which case the operation is still useful. It seems I'll have to wait for VC module system to see how the operation is actually used in the code.

2. Totally failed to make a vertex-animated scene prop actually move with (prop_instance_deform_in_cycle_loop) operation. Playing with scene prop flags did not help. Maybe there are some new flags now. Didn't yet test other operations from this group. Has anyone had any success with them?

3. Facekey operations dealing with hair texture and skin color seem to have no effect at all. Changes to these values seem to persist, but if I go into face editing screen and return back to game they are immediately reset to zero (even if I didn't change anything).

4. Operations (face_keys_get_morph_key) and (face_keys_set_morph_key) are a bit of disappointment. They work perfectly fine, but only first 8 morph keys are accessible out of 27 (from chin_size to cheeks, as defined in module_skins.py file).

5. Effects of operations (party_{get/set}_ignore_with_player_party) is a bit uncertain and needs more testing as my experiments have proved inconclusive so far. It is also not clear what the operation second parameter stands for (radius? time? modifier to aggressiveness?). Also, get operation syntax comments seem to be incorrect (there's no destination parameter mentioned). Again, it seems I'll have to wait for VC module system to clarify.

Another issue is more organizational in nature. It is not enough to update the header_operations.py file, there are some related changes in process_operations.py as well, and I strongly suspect that some other header and/or process files will be affected by 1.161-1.165 patches. This means that there won't be an official release for this project until new module system is officially available from Taleworlds (I will be posting download links until that time, but they will be for testing purposes only, and not recommended to use in actual projects to prevent possible conflicts later on).
 
Those who are interested can download current version of the file.

Attention! This is a version in development and archive contents will be changed in the nearest future.

Archive includes reference for new operations (they're not yet allocated to appropriate sections) and lots of minor fixes/improvements for the rest of the file. I have also prepared multiplayer operations section for adding comments but haven't started yet. Also included is the modified process_operations.py file to properly handle the new try_for_prop_instances operation.

Waiting for Module System release by Taleworlds before doing the final research on new operations and publishing the v1.0 release.
 
Okay, the ModSys has finally been released after a long and tortuous wait. :smile:

There's lots of new stuff in there, including some new operations which have not been reported before.

Apparently Taleworlds forgot to fix their process_operations.py files to account for new cycle operations (try_for_prop_instances and try_for_players), so the vanilla compiler patch will be included in the new version.

Unfortunately, Viking Conquest ModSys has not been released yet, so I still had no opportunity to see some of new operations in action. In some instances, this makes it pretty hard to understand what and how they actually do.

On a funny note, apparently some comments from this project have somehow made their way into the official Taleworlds Module System. :wink:
 
[size=16pt]Version 1.0.1 Released.​

Thanks to guspav, added (agent_set_ranged_damage_modifier) operation from 1.157 patch that I somehow missed in the past.

All other operations are accounted for.
 
Code:
server_set_combat_speed                      =  479  # (server_set_combat_speed, <value>),
                                                     # Official docs: 0-2

<value> is actually 0-4, going from slowest to fastest, you can see it's used in module_presentations from 0 to 4
 
This is really great! I learned a lot from it. What is the current version of the file?

agent_set_ammo:
agent_set_ammo  = 1776  # (agent_set_ammo, <agent_id>, <item_id>, <value>),
# Sets current agent ammo amount to the specified value between 0 and maximum ammo. Not clear what item_id means - weapon item or ammo item? 4research.

I tested it in NW on multiplayer and I found out that it only works for items such as bullets and grenades, so item_id in this case is for ammo type, for example: itm_bullets or itm_grenade or itm_pistol ammo (all three tested and they work).
To refill guns ammo you need to use the type of ammo that it uses, so you can't refill player's musket ammo if they don't have that type of cartdridges. It's different with grenades, because it just uses grenades item_id (itm_grenade). The max value for any kind of weapon that you can use is it's max_ammo value in module_items.py. Example:

Code:
(agent_set_ammo, ":agent_no", "itm_grenade", 5),
(agent_set_ammo, ":agent_no", "itm_bullets", 10),
 
There is something else I recently noticed:
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.

Actually it does return prop_instance_id as reg0. Tested in Napoleonic Wars.


Edit: I just realised that last post in this thread was in 2015...
 
Back
Top Bottom