April 19, 2024, 12:22:49 AM

Username
Password

  Show Posts
Pages: 1 2 [3] 4 5 ... 66
31  Warhammer Dark Omen / Singleplayer / Re: Further CTL investigation 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)
32  The Remake Project / General Suggestions / Re: Dark Omen Reborn on: April 20, 2017, 10:36:09 PM
Thanks, the new BTB Editor could be convenient compared to Robs legacy one. Did you figure out anything new about BTB during the last years? Same question applies to PRJ.
33  The Remake Project / General Suggestions / Re: Dark Omen Reborn on: April 20, 2017, 07:26:44 PM
Are source and download of that BTB and SPR Ui tools available somewhere?
34  Modifications / Campaigns / Re: New Campaigns: Questions and suggestions on: April 19, 2017, 10:39:31 PM
The 24 chars in PLYR_ALL.arm is unfortunately hardcoded, extending this is tricky because you have to patch tons of locations in the code.
35  Modifications / Campaigns / Re: New Campaigns: Questions and suggestions on: April 19, 2017, 06:33:13 PM
Havn't tested this:

#95 seems to be:

Returns false when the current regiment is currently casting a spell or when the 1st argument is != 0. (I only see #95 0 usage in CTL)

Then #95 takes the last event the unit received and stores the following information:

(Note: An event can provide 5 arguments, the 1st is usually the origin, the other 4 depend on the event)

Code:
Source: (arg1) Becomes the spell target
counter: arg2
magic to use: arg3
target x: arg4
target y: arg5
x and y are only used when source is 0, otherwise source is the target.

So we need a CTL function that can populate args 3-5. I found two: cast_spell and cast_spell2 (badly named Wink).
cast_spell:
Code:
1st argument: Event to generate (usually 66). The counter is set to 1.
The event is sent to the caller of this function (makes sense).
The spell target is either the close combat target if available, or the x/y coordinates specified in that 95h-event (there are probably other ways to populate that 95h-event)
2nd argument: The flag the spell must have (I'm not sure yet how to specify exactly which spell you want exactly...)
3rd argument: Maximum amount of spell points of the spell (Wand of Jet is respected)
When 1st arg is "-1" the function checks if any magic item/spell fulfilles the condition (and sets true/false).

cast_spell2:
Same as cast_spell, but the target is the caller. When dispell magic is picked the counter is 3, otherwise 1.

#9c is able to replace arg4 and arg5 of that stored event (and does some other stuff, not investigated yet).

#8e is usually used after #95 returned true:
8e uses the data prepared by #95 and casts the spell when the unit has the specific spell and returns true in that case.
The counter is decremented by 1, when it reaches 0 the data stored by #95 is cleared.

#96: Returns true when the current unit is NOT a wizard or the magic specified by #95 is NOT a spell (so a magic item e.g.)
This is only used in func 124, for true it calls #8e, otherwise returns to func 117

func 117 invokes #81
#81: When the 1st argument is 1 (is the case for 117):
This function does some kind of distance check between the current regiment and the spell target. No idea what the purpose is.

Example usage: Necromancer in B1_04 (Bandit ambush before Bogenhafen):
Code:
init_teleport_spell 16 ; Use coordinates of BTB_6000 element 16
; init teleport also resets the CC target and sets arg4 and arg5 of the 95h event
; Maybe init_teleport_spell is actually a bad name, this is maybe to force a spell
; cast location even while in CC I guess.
set_unit_flag2 16 ; No idea
add_magic_points 3
cast_spell 66, 256, 3 ; Has no CC target, spell target will be the BTB_6000 obstacle

So I don't see a way yet how to reliable use a specific magic item...

Event 74: Broadcasted to the other regiments in the casters team. Unused it seems, arg3 is the magic (item) used.

Only used in tutorial:

#e5: Returns true when unitid arg1 is currently casting a spell at unitid arg2.

#e9: Return true when unitid arg1 has magic item/spell with id arg2.
36  Modifications / Campaigns / Re: New Campaigns: Questions and suggestions on: April 18, 2017, 04:47:45 PM
Here is the formula for unit replacement: http://forum.dark-omen.org/troops/troop-replacement-cost-formulas-t881.0.html;msg9110#msg9110

Event 78 is sent to a fanatics owning regiment when somebody is close enough (also obvious by looking at the event script Wink)

37  Warhammer Dark Omen Community / Tavern / Re: Total War Warhammer on: February 18, 2017, 06:37:58 PM
The game is available in the current humble monthly ($12) btw.
https://www.humblebundle.com/monthly
38  Warhammer Dark Omen / Singleplayer / Re: The hand on: February 08, 2017, 06:40:14 PM
See this video: https://www.youtube.com/watch?v=PZ9n-0tDhkE

Mortar aim skill is important
39  The Remake Project / General Suggestions / Re: Question about the Remake project on: December 19, 2015, 09:52:08 AM
Well. I'm not very into game development but I evaluated some enginges (CryEngine, Unreal, Unity) a while ago. But usually I only contribute to open source projects which are usually using there own engine programmed via SDL2 for portability. The remake project by Mikademus used the Ogre engine. But this was before all the commercial engines got basicly free.
For a university project I used the Unreal Engine but I didn't liked it. Very bad documentation and if you want to write anything except shooters you can throw everything except the core away.
I would probably use Unity for this. No specific reason, any engine would work. I just think that the workflow with Unity is great and you have a nice script language (C#).
40  The Remake Project / General Suggestions / Re: Question about the Remake project on: December 16, 2015, 01:22:02 PM
Yeah 4vs4 would be nice to have but that should not be a goal for the beginning.

As you say it should be like Dark Omen with all it's strategic components (morale, flanking, line of sight) and co. ... and magic and magical items that are not too imba. You also don't need a campaign (yet). Just Skirmish mode and a nice unit editor -> Done.
41  The Remake Project / General Suggestions / Re: Question about the Remake project on: December 16, 2015, 12:09:03 PM
I hope there will be a nice remake someday Smiley

No, Olly, don't get too happy. I don't have any secret project running.
42  The Remake Project / General Suggestions / Re: Getting started. on: November 17, 2015, 11:10:04 PM
Flaks Goblin Campaign is not that hard
43  Modifications / Troops / Re: Troops: Stat bonus per level on: November 15, 2015, 08:12:16 PM
I merged the topics, couldn't find the original one yesterday
Yeah, if 0-999 exp is Level 1 I mean Level 2, 3 and 4. Sorry.
44  Modifications / Troops / Stat changes based on level on: November 14, 2015, 10:34:23 PM
Due to popular request, levels accumulate, level 3 gets all 1 and 2 bonusses:
(1 level = 1000 exp)

weaponSkill: Level 1: +1 if not missileWeapon
ballisticSkill: Level 1: +1 if has missileWeapon
strength: Level 2: +1
toughness: Level 3: +1
leadership: Level 2: +1
45  Warhammer Dark Omen / Singleplayer / Re: Victory over Black Grail does not count. why? on: November 14, 2015, 10:31:25 PM
A quick check says that unit_id 257 is the checked objective... so no idea :/

Can be also confirmed in WHMTG script:

CheckObjective 9
IF == 1
    SetVariable var_09 1
ENDIF

And this var_09 is checked in black pyramide level then...
Pages: 1 2 [3] 4 5 ... 66