OSP Kit Optimisation Warband Module System 1.166 (with tweaks and giggles)

Users who are viewing this thread

Since we talk about server-side exclusive trigger parameters, I'd like to clarify which triggers can be used client- and/or server side.
I'll only list multiplayer relevant triggers ofc;

ti_server_player_joined# server side
ti_on_multiplayer_mission_end# server/client side
ti_before_mission_start# server/client side
ti_after_mission_start# server/client side
ti_on_agent_spawn# server/client side
ti_on_agent_killed_or_wounded# server/client side
ti_on_agent_hit# server side
ti_on_player_exit# server side
ti_on_init_scene_prop# server/client side
ti_on_scene_prop_hit# server/client side
ti_on_scene_prop_destroy# server side
ti_on_scene_prop_use# server side
ti_on_scene_prop_is_animating# server/client side
ti_on_scene_prop_animation_finished# server/client side
ti_on_scene_prop_start_use# server side
ti_on_scene_prop_cancel_use# server side
ti_on_init_item# server/client side
ti_on_weapon_attack# server side
ti_on_missile_hit# server/client side ### not all hits will be registered client side
ti_on_item_picked_up# server side
ti_on_item_dropped# server side
ti_on_agent_mount# server/client side
ti_on_agent_dismount# server/client side
ti_on_item_wielded# server/client side
ti_on_item_unwielded# server/client side

It might be worth to add that info :wink:
 
Just out of interest, will the old tutorials still apply for this? As in, will the old tutorials by Armagan and others become useless with this? It looks like a lot has changed.
 
Old tutorials are still mostly valid - they don't have information about a lot of features, but the basic framework stayed the same since early M&B days.

And great thanks to everyone who's contributing here.

BTW I'd like to get clarification on server-only triggers - do they fully match singleplayer mode, or are there any differences? With the obvious exceptions like ti_server_player_joined, of course. :smile:
 
Lav said:
BTW I'd like to get clarification on server-only triggers - do they fully match singleplayer mode, or are there any differences? With the obvious exceptions like ti_server_player_joined, of course. :smile:
The server-only triggers do work in SP like they do in MP, except for ti_server_player_joined, ti_on_multiplayer_mission_end and ti_on_player_exit which simply don't work in SinglePlayer.
 
Updated the download to include all information provided here in the thread.

Great thanks to all involved!

Also since Taleworlds released the bugfixed module system as 1.166, I have updated module system version to match.
 
version 1.167 has two new operations (its currently on beta with Viking Conquest 1.04beta).

mission_tpl_are_all_agents_spawned                = 1943  # (mission_tpl_are_all_agents_spawned),
OPCODE 62 => no idea what it is called

just a heads up
 
Quite important note - "try_for_prop_insances" takes two additional parameters, not one. It should look like this:

(try_for_prop_instances, <destination>, [<object_id>], [<object_type>]), # if object_id and object_type is not given, it loops through all instances.

Object types are:

somt_object = 1
somt_entry = 2
somt_item = 3
somt_baggage = 4
somt_flora = 5
somt_passage = 6
somt_spawned_item = 7
somt_spawned_single_ammo_item = 8
somt_spawned_unsheathed_item = 9
somt_shield = 10
somt_temporary_object = 11

If using <object_id> parameter  <object_type> parameter should be set as well. Otherwise you can end up with some errors.

For example - you want to run the loop for specific scene prop kind, like this (try_for_prop_instances,":instance","spr_my_prop"). The operation will not only check for the instances of chosen prop kind, but also for any other instances (items, entries, passages... etc.) which have the same ID number. So in order to really check for prop "spr_my_prop" your loop should look like this: (try_for_prop_instances,":instance","spr_my_prop", somt_object)
 
So somt_object would be for example an usual object?
And somt_flora would be each spr with the sokf_handle_as_flora flag?

And where should I define them?

Btw. anyone knows, if the new try_for_players is more performant than the usual way by using get_max_players & try_for_range,":player",0,":max" ?

Edit: Another question, is player_is_active still necessary in the try_for_players operation?
 
So somt_object would be for example an usual object?

If by usual object you mean scene prop, then yes. :wink:


And where should I define them?

Anywhere you want. For example in header_common or module_constants.


is player_is_active still necessary in the try_for_players operation?

Yes and no. I found out that "try_for_players" can give you "invalid player id" error but only on dedicated server and for player 0. In other words, dedicated servers, even that they are player no. 0, they do not count as active players. So to be safe you should use "player_is_active" in "try_for_players" loops that do not use the skip server parameter.
 
so is this the scripting sdk reference dll??

im new to all this and mostly program in c languages (c++, C#) but if someone could help get me started, Id love to start writing my own scripts to change gameplay.
 
  • LootingScumbag said:
    so is this the scripting sdk reference dll??

    im new to all this and mostly program in c languages (c++, C#) but if someone could help get me started, Id love to start writing my own scripts to change gameplay.

    This is a custom tuple-based scripting framework/language built in Python to generate the .txt files read by the game.

    Adds high-level opcode and constant propagation and makes it easy to define triggers and add additional scene props, scenes, items, races and more.

    The download comes with the full source files used to compile (or build) the original Native module as written by the developers. You change the output directory in
    Code:
    module_info.py
    (point it to your own copy of the Native module) and regenerate the .txt files by running
    Code:
    build_module.bat
    . You don't need to restart the game to see the changes, you can force a .txt reload by using the Reload module data option in the menu bar, visible in windowed mode (just don't do this during action mode or you will force a funky respawn).

    Mods modify those files to add custom scripts, items, triggers and their changes in source form may or may not be publicly available.

    There's no binary editors or native-code dependencies (such as in Valve games), the only editor you will need is called OpenBRF and comes from a third party (a modder). BRF files are binary resource packages that store libraries of game assets (models, materials, texture references, collision bodies, animations, shader references, ...) and only needed if you need to change, override or add any assets.

    [+]The scene editor comes built into the engine as long as you enable Edit mode in the Misc options of the launcher.
    Just enter a scene and press Alt + Enter to switch to windowed mode and Ctrl + E to open the editor.

    [+]There's a base scene code generator in the global map action bar (only visible while in Edit mode) right next to the Camp option.

    [+]Also, pressing Ctrl + E in the overall map will show you the current player coordinates, useful for positioning entries of
    Code:
    module_parties.py
    .

    [+]You can reload the shaders file (an HLSL FXO file renamed as mb.fx in your module folder) on the fly by pressing Ctrl + F.
There is your quick Mount&Blade modding rundown for technical people.
 
Swyter said:
  • LootingScumbag said:
    so is this the scripting sdk reference dll??

    im new to all this and mostly program in c languages (c++, C#) but if someone could help get me started, Id love to start writing my own scripts to change gameplay.

    This is a custom tuple-based scripting framework/language built in Python to generate the .txt files read by the game.

    Adds high-level opcode and constant propagation and makes it easy to define triggers and add additional scene props, scenes, items, races and more.

    The download comes with the full source files used to compile (or build) the original Native module as written by the developers. You change the output directory in
    Code:
    module_info.py
    (point it to your own copy of the Native module) and regenerate the .txt files by running
    Code:
    build_module.bat
    . You don't need to restart the game to see the changes, you can force a .txt reload by using the Reload module data option in the menu bar, visible in windowed mode (just don't do this during action mode or you will force a funky respawn).

    Mods modify those files to add custom scripts, items, triggers and their changes in source form may or may not be publicly available.

    There's no binary editors or native-code dependencies (such as in Valve games), the only editor you will need is called OpenBRF and comes from a third party (a modder). BRF files are binary resource packages that store libraries of game assets (models, materials, texture references, collision bodies, animations, shader references, ...) and only needed if you need to change, override or add any assets.

    [+]The scene editor comes built into the engine as long as you enable Edit mode in the Misc options of the launcher.
    Just enter a scene and press Alt + Enter to switch to windowed mode and Ctrl + E to open the editor.

    [+]There's a base scene code generator in the global map action bar (only visible while in Edit mode) right next to the Camp option.

    [+]Also, pressing Ctrl + E in the overall map will show you the current player coordinates, useful for positioning entries of
    Code:
    module_parties.py
    .

    [+]You can reload the shaders file (an HLSL FXO file renamed as mb.fx in your module folder) on the fly by pressing Ctrl + F.
There is your quick Mount&Blade modding rundown for technical people.

Wow thanks for writing all this up for me. Going through it now!
 
Code:
agent_get_action_dir                     = 1767  # (agent_get_action_dir, <destination>, <agent_id>),
                                                 # Retrieves the direction of current agent's action. Possible values: invalid = -1, down = 0, right = 1, left = 2, up = 3

It seems another possible value is 5 which is returned if the agent is blocking with a shield or fists.
Haven't figured out 4 though.
 
Kipper said:
Code:
agent_get_action_dir                     = 1767  # (agent_get_action_dir, <destination>, <agent_id>),
                                                 # Retrieves the direction of current agent's action. Possible values: invalid = -1, down = 0, right = 1, left = 2, up = 3

It seems another possible value is 5 which is returned if the agent is blocking with a shield or fists.
Haven't figured out 4 though.

Thx man. Very usefull stuff.

Maybe 4 is for chamber block. Or maybe  when holding bow or other stuff that cant block with.
 
Hello everyone,

I have a simple question : if I want to start modding today, in march 2017, should I use this improved 1.66 module system, or the official 1.71 module system?
There's lots of outdated tutorials out there and it's generally hard to know what to do as of today.  :smile:

Thanks very much
 
Skeggjold said:
Hello everyone,

I have a simple question : if I want to start modding today, in march 2017, should I use this improved 1.66 module system, or the official 1.71 module system?
There's lots of outdated tutorials out there and it's generally hard to know what to do as of today.  :smile:

Thanks very much

You dont have much choice as up to date module system is essential if you wanna just mod without errors every  5 min. Not wanna say that its impossible to port improved version to updated one, but I doubt you need its features anyway if you starting with modding. However version improved  by lav has superior documentation for nearly all operations and triggers. So use newest module system in your mod folder but use lav one as modding reference.
 
Back
Top Bottom