August 16, 2018, 03:27:43 AM

Username
Password

Pages: 1 2 [3] 4 5   Go Down
Print
Author Topic: Further CTL investigation  (Read 17519 times)
0 Members and 1 Guest are viewing this topic.
cuthalion
Campaign Creator
*
Offline Offline

Posts: 370


View Profile
« Reply #30 on: May 24, 2015, 09:20:25 PM »

Another reminder.

test_units_alive_le_i 128, 4
iftrue
 blablabla (for example set register to 0 and throw self in battle)
endif

This function, as the name hints, returns TRUE if there are <4 units left under AI control. Hard to say whether <4 or <=4, and also if neutral units count. I am not sure what 128 means. Probably it indicates enemy side. The function in bundle with set_timer/wait_for_timer helps to organise enemy units flow non-stop rather than a number of waves.
Logged
Ghabry
Developer
*
Offline Offline

Posts: 1009



View Profile
« Reply #31 on: June 20, 2015, 03:17:53 PM »

I made a minor update to ctldis. This renames all the regiment_search functions.

Important update instructions because keywords changed:

1. Use the old ctldis in assembling mode (mode=0) to create a CTL.
2. Replace the _orig.ctl file in the directory with your CTL file.
3. Use the new ctldis in dissambling mode (mode=1) to create new script.txt
4. Use new ctldis in assembling mode (mode=0) to create the CTL

The first argument of all search functions is the event_id that is sent to the callee from the found regiment (Except if -1). The 2nd and 3rd argument vary depending on the search function.

Difference between the search functions from a low level point of view:


                               distfunc unittype unk nth  dist uflag1 attribs
search_regiment_uflag_attrib   0        0        0   1    100  arg2   arg3
search_regiment                0        0        1   1    100  0      0
search_regiment_2              1        0        0   1    100  0      0
search_regiment_3              1        0        1   1    100  0      0
search_regiment_unittype       0        arg2     0   1    100  0      0
search_regiment_unittype_2     0        arg2     0   1    100  0      0
search_regiment_nth            0        0        0   arg2 100  0      0
search_regiment_nth_2          0        0        1   arg2 100  0      0
search_regiment_unittype_nth   0        arg2     0   arg3 100  0      0
search_regiment_unittype_nth_2 0        arg2     0   arg3 100  0      0
search_regiment_distance_uflag 4        0        0   1    arg2 arg3   0



- distfunc: Distance function used, no idea what the difference is
- unittype: Unittype that the searched unit MUST have.
- unk: When 1 does something I couldn't figure out
- nth: Not completly sure, my guess is the list of found regiments is sorted and then the n-th regiment is picked (where 1 = the closest)
- distance: Search distance (not sure how big a 100-circle is)
- uflag1_xtra: Unit Flag 1 bits that searched unit most NOT have, inactive/retreating and similiar units are never found
- attribute: Attributes that the searched unit must NOT have, e.g. 4096 = engine of war

As you can see search_regiment_nth and search_regiment_nth_2 are the same... same for search_regiment_unittype_nth and search_regiment_unittype_nth2

* ctldis.py (14.13 KB - downloaded 111 times.)
Logged

olly
Global Spokesperson
*
Offline Offline

Posts: 1870



View Profile
« Reply #32 on: June 20, 2015, 05:58:28 PM »

Great Thanks!

Smiley
Logged

and back in Nuln, the ageing Graf Berhardt smiled his secret smile of pride whenever he heard the latest tales of his eldest son's ever growing chain of glorious victories -(sothr manual)
cuthalion
Campaign Creator
*
Offline Offline

Posts: 370


View Profile
« Reply #33 on: June 21, 2015, 08:44:20 PM »

Ghabry, could you give us a few examples of where these functions are used and how you interpret the logic?
Logged
Ghabry
Developer
*
Offline Offline

Posts: 1009



View Profile
« Reply #34 on: June 21, 2015, 10:14:55 PM »

Isn't the table clear?
Code:
search_regiment_uflag_attrib 4, 0, 4096
Send event 4 to callee when a unit (flags is 0 = don't matter except retreat) that isn't a steamtank (4096) is in normal (100) distance.

More interesting:
Code:
test_self_at_node 9
iftrue
    ; When at node 9 do a normal distance (100) search
    ; for units that are not in close combat (UnitFlag1 = 512)
    ; and send event 58 to callee if found
    search_regiment_distance_uflag 58, 100, 512
else
    ; When we are not at node 9 still search for enemies at close distance (50)
    search_regiment_distance_uflag 58, 50, 512
    iffalse
        ; When we are not moving (UnitFlag1 = 16) then continue moving to node 9
        test_unit_flag1 16
        iftrue
            move_to_node 9
        endif
    else
        ; Unit was found, guess event 58 will handle the attack
        block_movement
        sleep
    endif
endif

And in the event handler you have
Code:
on_event 58
    #86
I guess #86 sets the event source as a target
Logged

cuthalion
Campaign Creator
*
Offline Offline

Posts: 370


View Profile
« Reply #35 on: June 22, 2015, 08:12:50 AM »

A few things/questions

1. Distance is usually measured in battle map coordinates. It is so for BTB blocks: range of node etc. It is so for ranged weapons: maximum range seems to be battle map coordinates. BTW 100 circle distance is less than shortbow range.
My guess is: if this is really a distance, then this is distance measured in percents, and 100% = ranged weapon maximum range.

 I always thought 50/75/100 to be a kind of probability rather than distance. In B101 and a lot of other missions enemy archers have the argument = 50 when they are not at main target point, and have argument 100 when they are.
And in B101, when second goblin archers regiment appears in the north: if you stand still, sometimes they come to shooting distance and fire at once - from maximum range that shortbow allows. And sometimes they come very close to your unit before they start sooting. This is why I interpreted 50 as probability: even if they see you in range, they do not always shoot at once.

2. All those flags: "in close combat", "steam tank", "fleeing" and all others - where can I get the list of them? or at least a list of known flags?

Logged
Ghabry
Developer
*
Offline Offline

Posts: 1009



View Profile
« Reply #36 on: June 22, 2015, 12:55:19 PM »

I think the only public list is here:
http://wiki.dark-omen.org/do/DO/CTL/Flags

But looks incomplete, guess I never published mine which is still filled with lots of guesses/assumptions/unknowns.
Logged

cuthalion
Campaign Creator
*
Offline Offline

Posts: 370


View Profile
« Reply #37 on: July 13, 2016, 07:31:06 PM »

In wood elf campaign, it was always disappointing for me when my rider archers did not chase retreating enemy: In the midst of battle automatic trample helps a lot. So I decided to figure out how I can force archers to 'CRUSH THEM!'.
The answer seems to be as follows ('seems' because I have not tested it properly yet)

func 125 is archers event handler.
Event 15 is when enemy breaks. I just copy-pasted code of event 15 from function 122 (event handler for cavalry and infantry) to function 125 and archers started chasing.
What I need to do now is to overwrite this part only for rider archers. Probably again, unit_id is the an only option.
Also, would be nice to test many_vs_many melee fights. Hope nothing is buggy there.
Logged
olly
Global Spokesperson
*
Offline Offline

Posts: 1870



View Profile
« Reply #38 on: July 13, 2016, 08:41:01 PM »

Sounds great, let me know if you need any tests. Does this behave differently from Always Pursue?


* WoodElvesAlwaysPersue.jpg (127.54 KB. 1024x723 - viewed 111 times.)

Logged

and back in Nuln, the ageing Graf Berhardt smiled his secret smile of pride whenever he heard the latest tales of his eldest son's ever growing chain of glorious victories -(sothr manual)
cuthalion
Campaign Creator
*
Offline Offline

Posts: 370


View Profile
« Reply #39 on: July 14, 2016, 05:31:33 PM »

It does. 'always pursue' prevents chasing troops from stop. They run after victim to the bitter end. By the way, the flag seems to crash the game when is set to archer regiments.

I wanted to make my cavalry archers trample enemies who break instead of standing still waiting for a command. For that I found a difference in event handlers for cavalry and archers which seems to be responsible for this very moment. And replaced.
Logged
olly
Global Spokesperson
*
Offline Offline

Posts: 1870



View Profile
« Reply #40 on: July 14, 2016, 06:13:20 PM »

Cool!

Smiley

Logged

and back in Nuln, the ageing Graf Berhardt smiled his secret smile of pride whenever he heard the latest tales of his eldest son's ever growing chain of glorious victories -(sothr manual)
Leilond
Ghoul
*
Offline Offline

Posts: 52


View Profile
« Reply #41 on: April 23, 2017, 10:49:41 AM »

Last days I had several intense CTL/EVENTS testing sessions. Chaged the code forward and backward, adding “play_self” and “play_other” OpCodes here and there; commented, changed handlers, added and removed undocumented code a lot of time. It was hard and fun, sometimes frustrating.
I undestands things a bit better now, and I add my consideration for the good of the community. Feel free to correct, comment and eventually use any part of this in the way you think it's better.
This is a VERY long post, thus take your time if you're interested in deep CTL analysis

EVENTS HANDLING
All units use the same way to handle events.
There is a “base” function (.func 121) that handles some events (66, 68, 69, 61, 65, 78, 48, 54, 1, 25, 57, 26, 9, 14, 22, 24, 48, 2, 5, 11, 10, 8, 16, 28, 29, 17) in the same way for all units.
There is a “specialized” function for each unit type (Ground units 122, Artillery 123, Wizards 124, Archers 125... didn't verified it there are other functions like “monster” or the like) that handles other events in a different way for for each unit type. The specialized function always call the “.func 121” base function after doing his event handling.
Each unit has his “personal” event handler, that can “override or complete” events controlled by “base” and “specialized” functions (or handle events unhandled) and then simply “call” the specialized function
An example of event handler for an infantry or cavalry is
Code:
.func 14
clear_ctrl_flag 8
do
get_event
on_event 4
#44
set_return_func_iftrue 127
end_event 6844
call 122
@0xABC
test_more_events
while
return_from_event_handler
In this simple handler example, we want the troup to do something different from “standard” for event 4 (the event generated by “search_and_attack_enemy 4, 0, 4096”) and then “call 122” to make the rest of the events to be handled in “standard way”.
If you use “end_event 6844”, this particular event (in our example “event 4”) will not be handled by other handlers, the script will jump to the 0xABC label and the next event will be handled. If you use “end_event 3567”,  the event will be eventually handled by other “on_event 4” statements in “base” and “specialized” functions.

This is the way events for enemy troups are handled in all  maps and thus the way we can do for our campaigns. Make an handler to manage some events, using “ end_event 6844” to completely ovveride en event or “ end_event 3567” to make some things happens before standard handling, and then call the correct specialized function (122, 123, 124, 125) to handle “standard” event actions.

I looked for event understanding since I started to make my personal campaign, because I felt immediatley that is the place where the secret of the perfect AI live.
This were all my “discoveries”

EVENTS
 - 61. Hit by ranged attack (spell too). The event seems to fire only if at least one shot landed (no matter if no casuality done because the unit is saved by armor or shield of plotos). Thus if a unit is under fire but for that round not a single hit reach the target, the event isn'f fired.
 - 5. Event fired when unit is being charged, in the moment the charge start (before the actual fight start, but after the “Charge!” cry is sent)
 - 10. The actual hand to hand fight started (no matter who was the charger)
 - 12. “Lost a hand to hand fight round or charged in the flank/rear” AND “failed the leadership test”. Usually this send back to “.func 126” (Artillery) or “.func 132” (all other unit type) that contains istruction to make the unit rout.
 - 22. Friendly unit completely destroyed
 - 52. Some heavy damage sustained by ranged attacks. I cannot say the correct value, but if a unit loses something around 25% of its alive members, this event fire up.
 - 79. Hit by a spell (fired before event 61).
 - 15. Enemy flee the hand to hand combat (rout)
 - 16. Unit succesfully regroup after routing
 - 25. Regroup after pursuing an enemy.
 
CTL OPCODES
 - #5b and #5d. This codes send the unit routing no matter what (I tried immune to fear and will never rout, but the code still send the unit retreating. I will try to update my “ctldis.py” and call this cod “unit_always_rout1” and “unit_always_rout1”.
 - test_self_afraid. First I thought this was a “test if the unit fail a fear test”, while it simply means that the unit is “vulnerable to fear”. Unit with “Will never rout” and/or “immune to fear”, always pass this test, while all other units always fail the test
 - search_and_attack_enemy. Big issue here. This opcode, diffently from what I thought and undestood at first read, DO NOT make the unit really start to go to the fight, but only verify if there is some possible enemy in sight, set the conditional flag to true and fire the arg1 event for the unit. Thus “search_and_attack_enemy 4, 0, 4096” will fire event 4 for this unit if there is an enemy in sight to fight, but the unit will stand still and go on doing what it was doing.  The event handler, for event “4”, usually contains “#44” and “set_return_func_iftrue 127”. In this “.func 127” there are these opcodes: “#14 4, -1”, “#48”, and finally “#4f”. This three codes will make the unit move versus the designed enemy and fight if they “contact”. To make the unit “charge” when at range, it is first tested that the enemy unit is at the right range to be charged (#58) and then (if true) the charge action is launched (#59). A better name for “search_and_attack_enemy” could be "test_enemy_to_attack_in_sight".
All this, in B101.CTL, this is performed by this code.
In “.func 0” there is this:
Code:
search_and_attack_enemy 4, 0, 4096
that fire the event “4” that is handled by “.func 14” with this code:
Code:
            on_event 4
                #44
                set_return_func_iftrue 127
                end_event 6844
And then all the functions called starting from ".func 127"
Code:
.func 127
    #14 4, -1
    send_event_to_stored_unit 20
    wait_unit_flag1_clear 16392
    play_self 1
    #48
    #4f
   ;now the unit start to walk toward the enemy
    do
        for 2
            set_timer 10
            #58
            ;#58 => test if the enemy is in range for charging
            goto_iftrue 129
            wait_for_timer
            test_unit_flag1 16
            iftrue
                restore_ip
            endif
        next
        #49
    always


.func 129
    #59
    ; #59 => Charge
    iftrue
        play_self 2
        #14 19, -1
        do
            sleep
            #b0 0
            test_unit_flag1 16
        whilenot
    endif
    goto 134


.func 134
    hold
    sleep
    wait_unit_flag1_clear 8
    #50
    restore_ip
   “.func 134” seems to be the end of the battle and is fired if the charge failed (#59 returned false) or the “unit_flag1 16” is 0 (I think this mean the unit is still fighting, pursuing or locked to attack an enemy).
 - search_and_shot_enemy. Apply the same consideration made on "search_and_attack_enemy". A better name could be "test_enemy_to_shot_in_sight"
 - #44. It's used to make some test and always followed by some sort of “set_return_func” statement to make the unit start a fight (usually .func 127). I'm sure the test is failed if the unit is routing. I can reasonably suppose that “#44” is a test for being sure the unit is “able to fight” (unit alive and not routing/fleeing/paralyzed/pursuing). I will try to update my “ctldis.py” and call this opcode “test_unit_can_fight”
 - #14. This is probably the not-documented opcode most used out there... being able to understand what this damn code do, could be an big improvement of CTL understanding
 - return. What's the meaning of any istruction after a “return” statement? It look like “wasted code”, isn't it? As an example, in B101, you find in “.func 122” a “return” statement followed by some othere statemens that I do not see how they can be executed and thus I cannot see their pourpose.
 - #58. Verify if the enmy unit is at the right range to be charged. I will try to update my “ctldis.py” and call this opcode “test_charge_range”
 - #59. Charge. I will try to update my “ctldis.py” and call this opcode “charge2” (because there still is another “charge” OpCode)
UNIT FLAGS
I find that a lot of “test_unit_flagX n” and “wait_unit_flagX_clear n” are made without apparently being any “set_unit_flagX n” (or clear) being anywhere. Is it possible that some of these flag are set/cleared by default in some situations?
There are “wait_unit_flag3_clear, wait_unit_flag3_set, test_unit_flag3”, but there isn't any “set” or “clear” for flag3... What does this mean? In B101.CTL there is “wait_unit_flag3_clear 8192”... this means that flag3 update is hardcoded in the game. This make manipulation of flags a bit dangerous if not perfectly understood, and thus I suggest to use “unit registers” instead of “unit_flags”, unless you know what you're doing

Hope this hepls someone to improve in CTL understanding
Logged
olly
Global Spokesperson
*
Offline Offline

Posts: 1870



View Profile
« Reply #42 on: April 23, 2017, 01:03:20 PM »

Fantastic! There's loads of useful info for the wiki and to put into Dark Omen 2

many thanks

Smiley
« Last Edit: April 23, 2017, 01:20:01 PM by olly » Logged

and back in Nuln, the ageing Graf Berhardt smiled his secret smile of pride whenever he heard the latest tales of his eldest son's ever growing chain of glorious victories -(sothr manual)
Ghabry
Developer
*
Offline Offline

Posts: 1009



View Profile
« Reply #43 on: April 23, 2017, 07:31:03 PM »

Thanks for your observations. About search and attack enemy did you see my post in this thread from 2 years ago? Based on my latest findings I'm updating the table:

Code:
                            distfunc unittype vision nth  dist uflag1 attribs op
find_enemy_uflag_attrib      0        0        0      1    100  arg2   arg3    a2
find_enemy_visible           0        0        1      1    100  0      0       a3
find_enemy_simple            1        0        0      1    100  0      0       a4
find_enemy_simple_visible    1        0        1      1    100  0      0       a5
find_enemy_unittype          0        arg2     0      1    100  0      0       a6
find_enemy_unittype_2        0        arg2     0      1    100  0      0       a7
find_enemy_nth               0        0        0      arg2 100  0      0       a8
find_enemy_nth_visible       0        0        1      arg2 100  0      0       a9
find_enemy_unittype_nth      0        arg2     0      arg3 100  0      0       aa
find_enemy_unittype_nth_2    0        arg2     0      arg3 100  0      0       ab
find_enemy_distance_uflag    4        0        0      1    arg2 arg3   0       ac

All of them generate arg1 as an event.

- distfunc: Looks like 0 is the direct (diagonal) distance, 1 just considers x or y (bounding box I guess), 4 is some smart thing that considers terrain e.g. (probably useful for archers).
- unittype: Unittype that the searched unit MUST have.
- vision: When 1 the vision of the caller is considered (worse when walking or fighting), except if you have 360° vision (spider) they always find everything
- nth: Not completly sure, my guess is the list of found regiments is sorted and then the n-th regiment is picked (where 1 = the closest)
- distance: Search distance used for the distfunc (not sure how big a 100 is)
- uflag1_xtra: Unit Flag 1 bits that searched unit most NOT have, inactive/retreating and similiar units are never found
- attribute: Attributes that the searched unit must NOT have, e.g. 4096 = engine of war

Also want to clarify other opcodes:
test_event_from_close_combat
This is slightly incorrect. That field is already populated when you select the enemy as a attack target.
Also archers/artillery use the same field to mark the target
so more correct is maybe "test_event_from_target"?

#5c: General purpose retreat
#5b: Same as #5b, considers the target (probably to invert the direction)
#5d: Same as #5c, inverts the retreat dir (needs test if forward or backward)

#86: This one is extremely similiar to #44. I would call this one "test_unit_can_fight" because #44 has an extra feature:
#44: Same as #88 but also checks if the sender of the last event is retreating (and returns false in that case)
#9f: Same as #86 (yeah, really)

#5a: General purpose charge (already named OP_charge)
You said #58 is a test if the enemy is in charge range. This seems legit.
#59: This sends event 7 to the unit being charged

According to my notes wait_unit_flag3_clear 8192 is "Walks to magic item", your question helped me to investigate the op-codes that are around it:

#d0: find_and_collect_item. arg1 is item to find (in the trading post they collect treasure 100)
#d1: only used when d4 is true: Takes the distance (func arg1) of magic item event-arg2. And returns TRUE and collects it when close enough.
#d2: Check if the unit currently collects an item and if the item matches event-arg2
#d3. This is already called test_event_arg3. Could be renamed: This checks if event-arg3 of the last event matches arg1 but this is in the magic item opcode group, so: It is only used in event 69. So 69 is very likely item dropped.
#d4: Only used with event 71, whatever that is. #d4 checks if any regiment in our party is already collecting the magic item specified in event-arg2 (which is an index in some struct) (TRUE if any)

everything after a "return" is dead code

#14: This is some multi-purpose crap. Depending on arg1 it can do 16 (!) different things. The 2nd argument is an event id. And the field of the regiment structure it works on is not documented by me yet. But because you said it is related to fighting I will trigger a fight and check in the debugger to see what it contains, maybe the ref to the enemy being fighted...

#3e registers a timer function for invoking #14 >.<
arg 1: arg to pass to 14
arg 2: run every nth script update

It is worth playing around with "#3c 240, 0" because the 1st arg is used as some distance for most of #14.

BACK TO #14:

I see 10, 12, 13. 12 for peasants. 13 for enemy. 10 for friends.

10 is related to fanatic releasing and generates event 78 which is obviously fanatic spawning.

12 is a mess. Could be related to screaming and running when enemy is close?

13. When the enemy is idling it searches for a unit to move to (basic attack logic?), if there is none it searches for a magic item and generates event 71 (aaah! That's how 71 is generated)

When non-idling:
Fanatics handling (event 78).
When it found a target it can shoot magic (items) through event 66.
Also permanently rescans for closer enemies and magic items. I guess attacking works over event 3. Event 3 invokes #43 which has branching for Steam tank (event 85) and everything else (event 7). Meh check this later again, because this gets worse...

So to want a completely stupid unit: Get rid of #3e.

Terminology for the next text: There are basicly two different types of "targets".
The Player can specify a target by clicking on the banner. The target is overwritten when in Close combat (CC) with somebody.
The other target is the 14h-target. Which is for the Player only populated when a regiment starts following a retreating regiment.

The enemy uses the 14h-target more: E.g. when moving to an enemy, 14h-target is set to this (havn't checked if target is also populated but would make sense - but at least in CC it is)

So will use 14h-target and target for the remaining text:

-----
Usages of #14 in B1_01:
Code:
on_event 19
#14 8, 4
end_event 6844
Sends event 4 to the caller (event source is sender of last event) when:
 - the sender of last event has a target
 - a distance check between caller and sender passes
 - caller has no target.

Note: Event 4 is:
Code:
on_event 4
#44 ; test can fight
set_return_func_iftrue 127
end_event 6844

Code:
on_event 20
#14 8, 4
end_event 6844

Code:
on_event 21
#14 9, 4
end_event 6844
Sends event 4 to the caller (event source is sender of last event) when:
 - The sender of the last event has a 14h-target
 - caller has a target
 - a distance check between 14h-target of sender and caller passes  

Code:
on_event 5
#14 5, -1
iftrue
send_event_to_stored_unit 21
endif
end_event 6844

Looks like this checks if the sender is a better candidate (distance-wise) then the 14h-target and sets 14h-target to sender if this is the case (sets TRUE)

send_event_to_stored_unit: E.g. for spawned zombies the stored unit is the wizard who spawned them. Field could have more purposes.

The event arg of #14 is ignored.

Code:
on_event 14
#14 18, -1
end_event 6844

When sender matches 14h-target the 14h-target is cleared.
When sender matches "stored unit" (see above) the "stored unit" is cleared.

When sender matches the target, then:
 - Makes no sense to me Smiley
 - Unsure: sourceless event 25 is sent to the caller when not in CC I think.
 - Sound effect 31 is played

event arg of #14 is ignored. Hardcoded to 25 (srsly).

Code:
on_event 22
#14 17, -1
end_event 6844

Same as 18, see above

Code:
on_event 11
#14 7, -1
end_event 6844

Also too chaotic for me.
One part of this is generating enemy sighted events.

The one who encountered something gets event 28 (source is the enemy who was sighted)
The one who was sighted gets event 29 (source is the one who saw him)

Event arg of #14 is ignored.

Code:
on_event 65
test_event_from_target
iftrue
test_unit_flag2 4
iftrue
play_self 22
endif
test_unit_flag1 512
iftrue
#14 17, -1
else
send_event_to_self 25
endif
endif
end_event 6844

17 was already explained above.

Code:
.func 106
reset_call_stack
#14 4, -1
wait_unit_flag1_clear 16392
play_self 1
#48
sleep
#4f
do
for 2
set_timer 10
#58
goto_iftrue 129
wait_for_timer
test_unit_flag1 16
iftrue
restore_ip
endif
next
#49
always

This sends event 5 to the current target. source is the caller.

The event of #14 is ignored, hardcoded to 5 (srsly).

Code:
.func 107
    reset_call_stack
    charge
    play_self 2
    #14 19, -1
    do
        sleep
        #b0 0
        test_unit_flag1 16
    whilenot
    goto 134

No idea. Result depends on the race. Does not generate events.

Code:
.func 116
    #62
    #50
    play_self 3
    #14 1, -1
    #4a
    send_event_to_self_iftrue 3
    sleep_iftrue
    clear_unit_flag1 17842328
    clear_unit_flag2 16
    goto 110

Called when a regiment starts retreating. The one following it sets the 14h-target to the one it follows.

No event generated.

Code:
.func 127
    #14 4, -1
    send_event_to_stored_unit 20
    wait_unit_flag1_clear 16392
    play_self 1
    #48
    #4f
    do
        for 2
            set_timer 10
            #58
            goto_iftrue 129
            wait_for_timer
            test_unit_flag1 16
            iftrue
                restore_ip
            endif
        next
        #49
    always

Already explained.

Code:
.func 130
    #14 6, -1
    block_movement
    do
        sleep
        #c6
    while
    do
        set_timer 20
        wait_for_timer
    always

Code:
.func 140
    set_event_handler 141
    #3c 64, 0
    do
        set_timer 10
        wait_for_timer
        #14 16, -1
    always

No idea.

Code:
.func 141
    clear_ctrl_flag 8
    do
        get_event
            on_event 52
                #14 15, -1
                end_event 6844
            @0xABC
        test_more_events
    while
    return_from_event_handler

Seems to be related to random movement. Adds a random number to the direction.

More possibilities for #14 not in the CTL:

2: Searches for a regiment using the normal find_regiment function (distance 100).

Sends event 4 (#14 evt arg ignored, yeah!) to the caller (source is the found regiment)

10: Standard handler for friends. Explained at the top.

11: No idea.

12: Standard handler for Peasants

13: Standard handler for AI

---

Objective L (12): The unit with this unit id will never get a white flag. Bernhardt has this on the Black Pyramide map.

---

I have a (quite incorrect) list of unit flags if you are interested.

Maybe is also worth to update ctldis so that it dissasembles unit flags into something more readable (or at least in hex so you don't need a calc to convert them Wink)
« Last Edit: April 24, 2017, 02:15:53 AM by Ghabry » Logged

Ghabry
Developer
*
Offline Offline

Posts: 1009



View Profile
« Reply #44 on: April 25, 2017, 07:05:55 PM »

I'm currently in the process of updating ctldis with the latest investigations and some prettifiers to get better output: https://github.com/Ghabry/ctldis

Also added Python 3 compatibility Smiley

e.g.:

clear_attribute ContainFanatics
instead of
clear_attribute 2097152

or

test_unit_flag1 Retreat | 0x8000
instead of
test_unit_flag1 40960
Logged

Pages: 1 2 [3] 4 5   Go Up
Print
Jump to: