Search results for query: *

K700 said:

I don't think this question applies to wse2, contact modders discord

Click to expand...

Actually I'm a modder myself and I don't think this can be solved by usual modding (either with Python or Module system).
It is true that the prisoner panel is described by module_tableau_materials.py, but this file only contains the UI and panel, that's why I personally believe that the captive posture and helmet removal are controlled by hardcore kernel codes.

Is it possible to allow prisoners to keep their helmets?

K700 said:

are you joking? these are operations

Click to expand...

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.

K700 said:

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

Click to expand...

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?

K700 said:

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.

Click to expand...

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.

K700 said:

behavior try_for_agents was set to default for the warband engine, check the operation description

Click to expand...

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?

Could you explain the 'extended try_for_agents operation-additional parameter for mission grid iterator.'? In my mod I used lots of such operation (i.e., to deliver magic damage to agents in an area), so if wse2 can improve its performance that will be quite helpful.

Could you please make an example of the wse2 operation '(store_current_trigger, <destination>)'?

For example, if in a script I want to check whether the script is called in the ti_on_agent_hit trigger, is the following code correct?
(store_current_trigger, ":trigger_type"),
(try_begin),
(eq, ":trigger_type", ti_on_agent_hit),
(store_trigger_param_1, ":inflicted_agent"),
(try_end),

In the new version my mod does not crash as frequently, but still in some cases:
Could you help me investigate the log again? Thanks.

Thanks. Is it possible for you to explain a little bit how you investigated the log, so next time maybe I can do it myself?

K700 said:

send full rgl_log.txt

Click to expand...

I removed all agent_deliver_damage_to_agent operations but my module now crashes with a different error
EXCEPTION_STACK_OVERFLOW (0xC00000FD, 0x00000000, 0x01406000)
What operation is wrong now? Thanks.

I personally feel this problem is easier to solve if we can have a flag in wse2, and the flag determines whether agent_deliver_damage_to_agent shall trigger on_hit again.

In a fantasy mod this operation is critical because it is the best way to mimic enchanted weapon, just imagine an enemy is hit by a frost sword, and not only the vicitim of the weapon, but some foes nearby will also be damaged and frozen.

Is it possible to add such flag? This mod works fine in old WSE, so I guess this loop-trigger is a new feature in WSE2, and can be opt in and out?

K700 said:

This is script error. Used agent_deliver_damage_to_agent operation inside ti_on_agent_hit trigger, so this causes a loop and stack overflow error
Also pay attention to the warnings "Unmatched try_end"

Click to expand...

Thanks. I do have many agent_deliver_damage_to_agent operations inside ti_on_agent_hit trigger because this is a fantasy mod and I used lots of such operations to simulate spells and enchantments. Shall I use a different operation, and which one do you suggest in this case?

I always got 'EXCEPTION_STACK_OVERFLOW (0xC00000FD, 0x00000000, 0x01206000)' when playing a mod, could you help me investigate this error?

Here are the complete crash log files.
https://drive.google.com/file/d/1TRCaJnFUivaqrebSEFAK6OZpZUsS22An/view?usp=sharing

You can download the module here: Module

And here is a save you can use. SaveFile

I'm playing a module which has fantasy troops. Those troops work fine in the vanilla game, but with WSE2, all those troops will show their feet, as shown in the attached image.

Any ideas on possible reasons and how can I solve this problem? Thanks.

Oh that's really helpful, thanks!

Another file that causes a tiny confilict is postFX.fx. Surprisingly, the vanilla file works with WSE2 but not vice versa. Is it OK to play WSE2 with the vanilla postFX?

One suggestion: in order to make WSE2 and vanilla MB (or maybe even WSE) coexist in one folder, is it possible to make the WSE2 executable file load a different shader file? Currently I need to backup CommonRes\core_shaders.brf so as to swap between WSE2 and WSE. What about making WSE2 run with a file with different name, such as core_shaders_wse2.brf?

WSE2 uses its own rendering and shader brf format, so if mod uses its own shaders, then author of mod should edit and recompile fx and package resource_shaders to brf. Check WSESDK for more info.

Could you please give us a more detailed instruction on how to solve the shader issue?  I'm not familiar with shader brf but I guess I can learn how to do the work with some more help.