Clarifying Module System Operations

Users who are viewing this thread

Lav said:
cmpxchg8b, could you please comment on these?
Lav said:
party_is_in_town                      =  130  # (party_is_in_town, <party_id>, <town_party_id>),
# Operation failed for all test cases, however is successfully used in Native. 4research.
party_is_in_any_town                  =  131  # (party_is_in_any_town, <party_id>),
# Operation failed for all test cases, however is successfully used in Native. 4research.
party_get_cur_town                    = 1665  # (party_get_cur_town, <destination>, <party_id>),
# Operation returned -1 for all test cases. However it is successfully used in Native. 4research.
All 3 rely on party AI behavior being ai_bhvr_in_town and the town being the AI target object. Did you test with other parties or just the player party? Could be that they just deprecated it, if I'm not mistaken Native always checks for party attachment in conjunction with this. If I were you I would test by calling party_set_ai_behavior to ai_bhvr_travel_to_party and party_set_ai_object on a town, and then see what happens when the party reaches the town (i.e. whether the aforementioned operations work).
Lav said:
add_companion_party                  = 1233  # (add_companion_party, <troop_id_hero>),
# Creates a new empty party with specified hero as party leader and the only member. Party is spawned at the position of player's party. Does it return spawned party's ID in reg0? Does it take spawn radius into account? Does it take any extra arguments? 4research.
Creates a new party from template pt_hero_party at exactly the player party position, adds one stack with the hero specified, sets flags to pf_limit_members, faction to no_faction, behavior to ai_bhvr_travel_to_point, and copies morale and hunger from the player party. Party id is not saved anywhere.
Lav said:
party_set_next_battle_simulation_time = 1667  # (party_set_next_battle_simulation_time, <party_id>, <next_simulation_time_in_hours>),
# Used in Native with -1 for next simulation time (apparently indicates NOT to simulate battle in the next hour). 4research.
From what i can see the code does this:
Code:
if (next_sim_time < cur_time - last_sim_time)
{
    last_sim_time = cur_time
    simulate()
}
so theoretically setting it to -1 would mean "simulate right away". It doesn't make much sense, though, does it? At least that's not what I would've gone for by looking at where it's used in the MS.
Lav said:
mission_get_time_speed                      = 2002  # (mission_get_time_speed, <destination_fixed_point>),
# Not documented. 4research.
mission_set_time_speed                      = 2003  # (mission_set_time_speed, <value_fixed_point>) #this works only when cheat mode is enabled
# Not documented. 4research.
mission_time_speed_move_to_value            = 2004  # (mission_speed_move_to_value, <value_fixed_point>, <duration-in-1/1000-seconds>) #this works only when cheat mode is enabled
# Not documented. 4research.
Used to speed up/slow down mission time. Can be used to create slow motion effects, for example.
Lav said:
team_set_order_listener                  = 1795  # (team_set_order_listener, <team_no>, <division>, <value>),
# Effects not clear. 4research. Taleworlds doc: merge with old listeners if value is non-zero #clear listeners if sub_class is less than zero
class_is_listening_order                = 1775  # (class_is_listening_order, <team_no>, <sub_class>),
# Checks that the specified group of specified team will listen to player's orders. It's not clear how it could be different though. 4research.
I'll leave these to Caba`drin, or any other expert on divisions and orders.
Lav said:
agent_set_no_dynamics                    = 1762  # (agent_set_no_dynamics, <agent_id>, <value>),
# Used in Native for the wedding scene. Effects not clear. 0 = turn dynamics off, 1 = turn dynamics on. 4research.
Basically turns off movement. The agent will still be able to turn or attack on the spot.
Lav said:
agent_get_combat_state                  = 1739  # (agent_get_combat_state, <destination>, <agent_id>),
# Retrieves agent's current combat state. Constants returned by this operation are not documented anywhere. 4research.
AI stuff, no idea what the values mean. Possible values are 0, 1, 2, 3, 4, 7, 8.
Lav said:
show_object_details_overlay                      =  960  # (show_object_details_overlay, <value>),
# Effects not clear, but used several times during the wedding ceremony. #0 = hide, 1 = show. 4research.
Enables/disables the tooltip (used for many things: display agent name, dropped item name, inventory item stats on mouse over...)
 
What variable's checked by {Brother/Sister}, {man/woman} tag on dialog? It seems not like {reg65?madame:sir} that simply we can control reg65 value to get right result.Nevermind. I found the solution.
 
Player's or troop's gender by default. At least that's my impression so far. :smile:

cmpxchg8b said:
cmpxchg8b, great thanks!

cmpxchg8b said:
All 3 rely on party AI behavior being ai_bhvr_in_town and the town being the AI target object. Did you test with other parties or just the player party? Could be that they just deprecated it, if I'm not mistaken Native always checks for party attachment in conjunction with this. If I were you I would test by calling party_set_ai_behavior to ai_bhvr_travel_to_party and party_set_ai_object on a town, and then see what happens when the party reaches the town (i.e. whether the aforementioned operations work).
I tested it on a different party, not player's. Maybe your idea re:ai_bhvr_travel_to_party will work, I didn't consider that possibility (though it means that the game must set something else when party reaches the town, otherwise at least one of the tests would succeed). Though right now I have the impression that the operation has simply been deprecated.

SonKidd said:
class_is_listening_order checks if SUB_CLASS of TEAM_NO is being selected for formation commands.
for example, caba uses it in this script: http://forums.taleworlds.com/index.php/topic,134031.0.html

(team_set_order_listener, <team_no>, <division>, 1), => SUB_CLASS of TEAM_NO will listen to command

(team_set_order_listener, <team_no>, <division>, 0), => SUB_CLASS of TEAM_NO will not listen to command
Oh, I finally got it. It's used to control hardcoded, not scripted behavior! Thanks again, will use!

Great, seems I have almost all information I need (except tableaus and mission/agents, I'm not an expert on former and the tests on latter are already planned). Official release is planned for this weekend, hopefully someone will be able to provide his input on tableau and multiplayer operations until that time, but even if that doesn't happen, that's no big loss. :smile:
 
As for party_is_in_any_town, etc, they function as desired when I've used them in the Freelancer mod code.

Example:
Code:
        ("enter_town",[(party_is_in_any_town,"$enlisted_party"),] ,"Enter stationed town.",
        [(party_get_cur_town, ":town_no", "$enlisted_party"),(start_encounter, ":town_no"),(change_screen_map),]),
The above allows the player to enter a town when the lord party disappears as attached. I believe (sorry I'm not being more helpful) that it has also allowed entering villages when the lord party is doing their 'collect taxes' runs...so travel_to_party may very well be checked.

SonKidd said:
class_is_listening_order checks if SUB_CLASS of TEAM_NO is being selected for formation commands.
for example, caba uses it in this script: http://forums.taleworlds.com/index.php/topic,134031.0.html

(team_set_order_listener, <team_no>, <division>, 1), => SUB_CLASS of TEAM_NO will listen to command

(team_set_order_listener, <team_no>, <division>, 0), => SUB_CLASS of TEAM_NO will not listen to command
Need to clarify the above a bit.

if grc_everyone (or non-existing division #9) is selected, class_is_listening_order will pass for any individual division 0-8, but only if grc_everyone is selected with it pass for division grc_everyone/9. 

(team_set_order_listener, <team_no>, <division # 0-8>),
or
(team_set_order_listener, <team_no>, <division # 0-8>, 0),
will set that 1 division as the only class/division listening to the order. It will not turn their listening off, as indicated above.

(team_set_order_listener, <team_no>, <division # 0-8>, 1),
will add to any previously selected divisions/classes and have them listen to the next order given by team_give_order as well.

(team_set_order_listener, <team_no>, -1),
will clear listeners so that no divisions are selected, but there is no way to remove 1 division/class at a time. Either overwrite it by using a 0 in the last argument, or clear it by using division -1

Note that for the mission_*_time_speed values, time speed defaults at 100% (so whatever that is depending on the fixed point multiplier, 10, 100, 1000, etc) and goes down to 1 (I do not know the highest value). One cannot do mission_set_time_speed to 0. The lowest value is always 1. You need cmp's WSE operation stop_time to get mission time to stop completely...which is good, as when mission time stops, it is left in the same frame so even every frame triggers do not fire.


agent_get_combat_state                  = 1739  # (agent_get_combat_state, <destination>, <agent_id>),
Values:
Code:
cs_free                      = 0
cs_target_in_sight           = 1     # ranged units
cs_guard                     = 2     # no shield
cs_wield                     = 3     # reach out weapon, preparing to strike, melee units
cs_fire                      = 3     # ranged units
cs_swing                     = 4     # cut / thrust, melee units
cs_load                      = 4     # crossbow units
cs_still                     = 7     # melee units, happens, not always (seems to have something to do with the part of body hit), when hit
cs_no_visible_targets        = 7     # ranged units or blocking iwth a shield
cs_target_on_right_hand_side = 8     # horse archers

# For the player or dead units it always returns 0.
# But for living human agents here are some of the values it can return and what each seems to mean:
# 0 = nothing active
# 1 = firing ranged
# 3 = preparing and holding attack (either melee or ranged)
# 4 = swinging with melee
# 7 = recovering from being hit
# 8 = ranged equipped, no target in field of view

agent_is_routed checks if the agent has already left the scene/faded out and has completed routing. Agents currently routing are "running away" and may be tracked by the running away/routing agent slot, but not by an operation (they can be stopped by agent_stop_running_away though).

agent_is_active is a test to see if the agent ID indicated is valid (if it fails, it won't throw up script errors, but any other agent-based operation that has an invalid agent ID will give a script error to that effect). Dead and routed agents still are valid agent ID#s, so this does not duplicate the functions of agent_is_alive or neg|agent_is_routed

agent_play_sound can be used in a mission (dialogs are partly mission-based in many ways) so the sound produced is localized in the scene and doesn't sound like it is coming from the player's location as in the simple play_sound

agent_equip_item works as advertised.

agent_start_running_away works as advertised. Agents run in a straight line to the nearest map border...sometimes through enemies unfortunately, so it isn't a particularly intelligent routing. This is the operation used to make agents route natively.

agent_get_division will return a division greater than 8, yes, but agents assigned to divisions greater than 8 (only possible by forcing it through agent_set_division) will not respond to any orders, even if they are scripted with team_set_order_listener and team_give_order. Probably would have been better to make those values fail in some way, but they don't throw up errors--they simply aren't functional.

on that topic, agent_set_division works as advertised...to a degree. Any time that an order (either through the player's order interface and the gk_order buttons or by team_give_order) is given to their original division (the division based on the troop_class, either weapon guarantee-flag set, changed with troop_set_class, or by the player in the party window) the agents who have been changed with agent_set_division will revert back to their original, troop_class-based division. This forces a routine loop to re-change divisions with agent_set_division if one wants to use that feature (every 1/2 second seems sufficient, though the player can still see a brief flicker of the changed divisions at this point).
 
Cool, thanks a lot! All those comments already halved the amount of test code I'll have to write, if not more.  :smile:

Meanwhile, I have added some introductory texts to most file sections. Thought to upload today, but considering the wealth of information provided by the community already, I'll probably complete the investigations first (since not that much work is remaining), and then jump directly to version 0.7 (or even 0.8 if I'll have time for argument renaming). After that only multiplayer stuff and final polishing remains. :cool:
 
Code:
(try_for_range, ':var', 0, 10),
end_try,

Sorry I can`t check at this time,  does variable coninue its life after ending cycle?
If I use ':var' after cycle end it will be 9 or error?
 
Operation try_for_range functions identically to for-cycles in normal programming languages. I even used this behavior in my scripts several times.

How cycle works:

1. Initialize iterator variable with starting value.
2. Check that it fits the constraints. If it doesn't, continue the code after the cycle.
3. Execute cycle code.
4. Increase the variable.
5. Go to step 2.

As you can see, after the last run when the variable is 9, it is increased once again before the cycle ends.

This is how cycles work in most programming languages, and Warband MS is no exception here.

Therefore, 10.
 
Never assume anything about Warband scripting. :razz:
Doing it like you say wouldn't work very well with agent or party loops (because "increase the variable" is actually "find the next valid index", so they actually check the constraints before incrementing the variable.
The loop will execute ten times, ":var" will range from 0 to 9, but it will stay at 9 even after the loop.
 
cmpxchg8b said:
Never assume anything about Warband scripting. :razz:
Doing it like you say wouldn't work very well with agent or party loops (because "increase the variable" is actually "find the next valid index", so they actually check the constraints before incrementing the variable.
The loop will execute ten times, ":var" will range from 0 to 9, but it will stay at 9 even after the loop.
Well, "foreach" cycles don't follow the described behavior pattern in other languages too. :smile:

Though for the sake of clarity, and since many Warband modders aren't programmers in RL, it's still better to clarify that what I said applies only to try_for_range and try_for_range_backwards operations. :smile:
 
Update on the complex party and town relationship.

Setting party AI behavior to ai_bhvr_travel_to_party and letting the test party reach it's destination was a success! After reaching the destination, party_is_in_town and party_is_in_any_town returned TRUE, and party_get_cur_town returned the party_id of the town in question. However party_get_attached_to returned -1. When I called party_attach_to_party after test party reached the town, calls to party_is_in_town, party_is_in_any_town and party_get_cur_town were still successful.

This means that what these operations actually check is that the party has reached the town normally. Also they can be used in combination with party_get_attached_to to detect that the party has reached it's destination but has not yet been processed and physically attached to the town.
 
Lav said:
Though for the sake of clarity, and since many Warband modders aren't programmers in RL, it's still better to clarify that what I said applies only to try_for_range and try_for_range_backwards operations. :smile:
What I meant is that it doesn't even apply to them. The above try_for_range will result in :var being 9, for example.
 
cmpxchg8b said:
What I meant is that it doesn't even apply to them. The above try_for_range will result in :var being 9, for example.
Erm? In Companions Overseer code IIRC I actually relied on (try_for_range) resulting in iterator being set to upper_range after the cycle is over. If try_for_range did not increase the iterator one more time after the last cycle run, Overseer code would simply not work properly. But it does.

A sec, I'll run a test.

UPDATE. Wow, it's actually 9. :shock: Damn, and I always thought different. :oops:
 
Ok, I have released current state as RC1 in another thread here:

http://forums.taleworlds.com/index.php/topic,213060.0.html

Kindly asking Caba'drin to determine where to move that thread, my suggestion would be Tools, but Tutorials might also do.

I'll leave this thread for any further discussion focused specifically on Module System operations.
 
Lav said:
UPDATE. Wow, it's actually 9. :shock: Damn, and I always thought different. :oops:

python cycle (for x in ...) use iterator
in the begining of each cycle it make somthing like:
Code:
try:
    x = iterator.next()  # it return next item or raise StopIteration exception.
except StopIteration: # handle exception 
    break # end cycle
 
Well, I don't really know Python yet (only learning), and anyway, it's not like Warband or it's Module System (after compilation) have anything to do with Python. :smile:
 
Lav said:
Ok, I have released current state as RC1 in another thread here:

http://forums.taleworlds.com/index.php/topic,213060.0.html

Kindly asking Caba'drin to determine where to move that thread, my suggestion would be Tools, but Tutorials might also do.

I'll leave this thread for any further discussion focused specifically on Module System operations.

Yes, moving the clear concluded ones to the tools board and keep the next discussion's nice idea. I hope the discussion will also includes flags of other module_*.py like animation's and sound's flags.
 
issue in native operation docs
Code:
cur_tableau_add_sun_light                        = 1991  # (cur_tableau_add_sun_light, <map_icon_id>, <position_no>, <red_fixed_point>, <green_fixed_point>, <blue_fixed_point>),

<map_icon_id> not needed.

Examples in native module_scripts (wb 1.143)
Code:
cur_tableau_add_sun_light , pos8, 175,150,125
cur_tableau_add_sun_light , pos8, 175,150,125
cur_tableau_add_sun_light , pos8, 175,150,125
cur_tableau_add_sun_light , pos8, 175,150,125
cur_tableau_add_sun_light , pos8, 175,150,125
cur_tableau_add_sun_light , pos8, 175,150,125
 
Back
Top Bottom