Warband Script Enhancer 2 (v1.1.2.0)

Users who are viewing this thread

Thanks. According to the operation description, try_for_agents have extra parameters to limit the search range: (try_for_agents, <destination>, [<position_no>], [<radius_fixed_point>]),

My question is: if I do want to limit the search range, is adding these two extra parameters better in performance than using the operation without the extra parameters, and then using get_distance_between_positions to check whether the agent is in range?

I have this question because by my understanding, try_for_agents works by going through a pre-saved array (or dictionary?) that contains the index of each agent, so I guess maybe those extra parameters (position_no and radius_fixed_point) work as an extra condition-check?
try_for_agents with position_no and radius_fixed_point works same as try_for_agents with get_distance_between_positions.
Performance is slightly better only due to fewer operations and less overhead on them.
try_for_agents with use_mission_grid gives much better performance since it goes through the mission grid rather than all the agents in the game, but you need to additionally use get_distance_between_positions if it is important for you to take into account the height in the agent position.
 
your op name is wrong.
actually is send_message_to_url = 380 # (send_message_to_url, <string_id>, <encode_url>),

What he said is that he want to use (send_message_to_url) in single-player mode native

K700, I want to confirm the real usage of it.
because we often call it in
(send_message_to_url, "@http://localhost:{port}/..."),

or can you show the code of the function send_message_to_url?
send_message_to_url standard Warband operation and it works in single player
 
try_for_agents with position_no and radius_fixed_point works same as try_for_agents with get_distance_between_positions.
Performance is slightly better only due to fewer operations and less overhead on them.
try_for_agents with use_mission_grid gives much better performance since it goes through the mission grid rather than all the agents in the game, but you need to additionally use get_distance_between_positions if it is important for you to take into account the height in the agent position.
Sorry I could not find any information regarding to use_mission_grid in the SDK folder, could you make an example for how to use this parameter? Thanks.
 
Sorry I could not find any information regarding to use_mission_grid in the SDK folder, could you make an example for how to use this parameter? Thanks.
check sdk from latest wse2
try_for_agents = 12 #(try_for_agents, <cur_agent_no>, [<position_no>], [<radius_fixed_point>], [<use_mission_grid>]), #Loops through agents in the scene. If [<position_no>] and [<radius_fixed_point>] are defined, it will only loop through agents in the chosen area. If [<use_mission_grid>] is non-zero, it will use mission grid iterator instead of searching through all agents. This is better in performance, but does not take into account the height of positions
 
check sdk from latest wse2
try_for_agents = 12 #(try_for_agents, <cur_agent_no>, [<position_no>], [<radius_fixed_point>], [<use_mission_grid>]), #Loops through agents in the scene. If [<position_no>] and [<radius_fixed_point>] are defined, it will only loop through agents in the chosen area. If [<use_mission_grid>] is non-zero, it will use mission grid iterator instead of searching through all agents. This is better in performance, but does not take into account the height of positions
Thanks, that's very helpful. Could you tell me where is this documentation? I did not find it in the WSE2 SDK folder.

Also, since it does not take into account the height of positions, does this mean it will be less accurate for flying agents (i.e. dragons and angels) when they are dealing damage to nearby ground agents?
 
Last edited:
are you joking? these are operations
In my mod I use try_for_agents to deal damage to agents in an area. For example, a dragon can breath fire to damage agents nearby. Since you mentioned that the operation does not count height if use_mission_grid is true, I just wonder whether it will become less accurate if, for example, the dragon is flying and breathing simultaneously.
 
Hi,

I'm also having the micro-freezing issue during battles in Prophesy of Pendor. The larger the battle size, the longer the freezes are. I usually play around 400 battle size though, and the issue is always present in large battles.

Here's my save game (right before a battle where the issue is present), config file, and log file. Let me know if there's anything else I can add to provide more insight. Thank you!
 
Will be fixed in the next update
Nice, thanks!

Are there any news concerning these two bugs?
1. Missing texture in Persistent Lords of the Ring

I've noticed there are some missing texture while playing at this mod, as seen in these pictures:

Image 1
Image 2
Image 3
Image 4

2. Prophesy of Pendor micro freezes during battle



I'm reporting this to you, however, because the resource consumption is very strange: when game freezes, instead of a high peak in the usage of hardware, there's a low peak, as show in these images from the monitoring program:

CPU usage
GPU usage


Please, apologies for the delay, but here's the save you've asked for. In it you'll find an ongoing campaing with a test character and plenty of troops in garrisons that you can take to assemble a huge army and, then, with Ctrl+T, you may look for a big enemy spawn around the map:

sg00.sav

Maybe, about the latter, we may see what we have in common with the other two users who reported it?

Concerning the settlements in Viking Conquest, the ones which show the misplaced water bug, you may start looking in Dore Hem East and Dun Taruo.
I've also noticed that in Aileach there's another occurrence of, apparently, a similar issue which, however, affects the sky, as shown in this picture here: Line over the sky (you need to zoom, there's a line crossing the frame just a bit above the mountains). I've noticed it appears sometimes in random battle scenes while using the A World of Ice and Fire mod, which is based on Viking Conquest.

There's also another very odd thing that I've noticed recently: the spyglass in Napoleonic Wars behaves very oddly now, as shown in this video:



Basically, the view changes to upside-down and it shows the agents as if they're seen by a much greater distance, in their low LOD form.
I swear this started from one of the latest WSE2 updates as I clearly remember I've previously used the spyglass to show a bug in this very thread.

Hope to have been of help and, please, do not heistate to ask me if you ever need some additional information.
 
Hi,

I'm also having the micro-freezing issue during battles in Prophesy of Pendor. The larger the battle size, the longer the freezes are. I usually play around 400 battle size though, and the issue is always present in large battles.

Here's my save game (right before a battle where the issue is present), config file, and log file. Let me know if there's anything else I can add to provide more insight. Thank you!
As well as Prophesy of Pendor, I have the same issue with A Clash of Kings. As soon as there are more than 200 or so troops in battle, the micro freezes kick in
 
send_message_to_url standard Warband operation and it works in single player
I test follow code a map trigger in single player mode. and web server did not received request.
Code:
(1, [
  (send_message_to_url_advanced, "@http://localhost:14725/", 'str_empty_string', "script_es_process_url_response", "script_es_process_url_response", 1),
]),

The WebServer use python3 aiohttp

WebServer ScreenShot
 
Last edited:
According to testing results, the same microfreezes are present in the vanilla engine as well. The higher FPS in WSE2 is the reason why microfreezes are more noticeable in WSE2.
The very reason for microfreezes is unoptimized scripts that do not work well with a larger number of agents. Previously it was suggested that these are moral scripts.
 
Are there any news concerning these two bugs?
Outer terrains with water will be fixed in the next update.

About spyglass - the bug is not reproducible for me.

About fishing net and Line over the sky - this is same for warband. Please always check if there is a bug in the vanilla engine, I spend a lot of time on useless reports.

Also, always attach not only screenshots, but also logs and save file with quick access to the bug.
 
Last edited:
According to testing results, the same microfreezes are present in the vanilla engine as well. The higher FPS in WSE2 is the reason why microfreezes are more noticeable in WSE2.
The very reason for microfreezes is unoptimized scripts that do not work well with a larger number of agents. Previously it was suggested that these are moral scripts.
Thanks for your efforts, is there anything we can do to alleviate this issue?
Will it be resolved in the next update?
 
Thanks for your efforts, is there anything we can do to alleviate this issue?
Will it be resolved in the next update?
This problem can only be solved by mod developers by reworking their scripts. While the engine executes scripts in one thread, this problem cannot be solved by the engine.
 
1.1.1.9
-Added acf_apply_slope_for_human animation flag.
-Added item_set_horse_skeleton_model operation.
-Fixed a bug with players spawn for multiplayer.
-Fixed function for removing tags for strings.
-Fixed outer terrains with water.
-Operation agent_set_attached_scene_prop works with any bones, not only with hard-coded.


Thanks to noooxy for sponsoring development.

For modders:

example
(str_store_replace_spaces_with_underscores, s0, "@new_skel_name"),
(item_set_horse_skeleton_model, "itm_saddle_horse", s0),
(skeleton_model_clean_body_sections, s0),
(skeleton_model_set_bone_body_section, s0, hrsb_tail_2, 1),
(skeleton_model_set_bone_body_section, s0, hrsb_head, 2),
...........

it is necessary to configure sections for new horse skeletons, since for all skeletons except "skel_horse" Warband makes sections like for a human skeleton
Code:
if (m_name == "skel_horse")
{
    m_lowerBodyBones = MAKEFLAG64(hrsb_tail_2) | MAKEFLAG64(hrsb_tail_1) | MAKEFLAG64(hrsb_r_back_hoof) | MAKEFLAG64(hrsb_r_foot) | MAKEFLAG64(hrsb_r_calf) | MAKEFLAG64(hrsb_r_thigh) | MAKEFLAG64(hrsb_l_back_hoof) | MAKEFLAG64(hrsb_l_foot) | MAKEFLAG64(hrsb_l_calf) | MAKEFLAG64(hrsb_l_thigh) | MAKEFLAG64(hrsb_r_front_hoof) | MAKEFLAG64(hrsb_r_hand) | MAKEFLAG64(hrsb_r_forearm) | MAKEFLAG64(hrsb_r_upper_arm) | MAKEFLAG64(hrsb_r_clavicle) | MAKEFLAG64(hrsb_l_front_hoof) | MAKEFLAG64(hrsb_l_hand) | MAKEFLAG64(hrsb_l_forearm) | MAKEFLAG64(hrsb_l_upper_arm) | MAKEFLAG64(hrsb_l_clavicle) | MAKEFLAG64(hrsb_spine_3) | MAKEFLAG64(hrsb_spine_2) | MAKEFLAG64(hrsb_spine_1) | MAKEFLAG64(hrsb_pelvis);
    m_rightSideBones = m_lowerBodyBones | MAKEFLAG64(hrsb_head) | MAKEFLAG64(hrsb_neck_3) | MAKEFLAG64(hrsb_neck_2) | MAKEFLAG64(hrsb_neck_1);
    m_allBones = m_rightSideBones;
}
else
{
    m_lowerBodyBones = MAKEFLAG64(hb_foot_l) | MAKEFLAG64(hb_calf_l) | MAKEFLAG64(hb_thigh_l) | MAKEFLAG64(hb_abdomen) | MAKEFLAG64(hb_foot_r) | MAKEFLAG64(hb_calf_r) | MAKEFLAG64(hb_thigh_r);
    m_rightSideBones = m_lowerBodyBones | MAKEFLAG64(hb_item_r) | MAKEFLAG64(hb_hand_r) | MAKEFLAG64(hb_forearm_r) | MAKEFLAG64(hb_upperarm_r) | MAKEFLAG64(hb_shoulder_r) | MAKEFLAG64(hb_head) | MAKEFLAG64(hb_thorax) | MAKEFLAG64(hb_spine);
    m_allBones = m_rightSideBones | MAKEFLAG64(hb_hand_l) | MAKEFLAG64(hb_forearm_l) | MAKEFLAG64(hb_upperarm_l) | MAKEFLAG64(hb_shoulder_l);
}
 
Back
Top Bottom