[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum
Recent Posts

Decided to move the experiments to the external 3d editor since I'm out of ideas.

Here're two options that I've tried (on the images you see x/y/z rotation channels):
[ Attachment: You are not allowed to view attachments ]
[ Attachment: You are not allowed to view attachments ]

First one looks similar to what I get in UE. On the second curve we see substantial overshooting and this looks like something DO uses (not exactly the same but in the same direction)! So the task is to find how DO devs calculated this curve (and tangents on the keys).

p.s. 03 00 XX XX overshoots much more than 03 04 XX XX command. Probably they differ either in curve type or in tangents of the same curve.

Don't add new units to the files in 1pbat.
The game expects a fixed size for this file and it will crash or not work. Same applies for savegames.

Hi

check out my guide to adding new units

http://forum.dark-omen.org/campaigns/how-to-create-new-mods-and-campaigns-t1251.0.html;msg12685#msg12685

For the Highking,

hey guys at first a special thanks for you.
in the past these forum has often helpe me and a big sorry for my bad english.

here my problem:

i would like to start the normal campaign with two more units
at first i added the new units with the "wh2edit" in plyr_alg.arm file in the 1parm folder
and in the file B101mrc.arm choosen in the 1pbat folder (iam not sure if the second must to)

after that i download the btb editor but i doesn´t now how to create the start point and in which "chunk" or "subchunk"
list i have to got to write down the "unique unit id"

so i hope you understood me 

Good work

After toying with SEQ a bit more I think they're using some kind of spline interpolation between the frames.

Rationale:

I've taken 1 sequence from 1.SEQ file (enemy sighted)

13 04 01 04
03 04 05 06
03 04 19 02
0A 01 00 00
02 00 00 00
08 00 00 00

Here we have 3 animation keys: 13->03->03

If interpolated linearly the animation never reaches the same position on the first 03 command as in DO (stopping much earlier). This is where I thought there's some kind of overshooting applied. So I nuked second 03 command from the sequence, leaving only 2 animation keys. Playing this sequence in DO resulted in unexpected (at least for me) result: the animation stopped at the same position as in my program! There was no overshooting at all.

After that I think there's some spline interpolation applied. Tried Catmull-Rom spline interpolation today (different parameterizations, including most famous uniform, centripetal, chordal), but it didn't overshoot at all. Moreover, this spline type requires at least 4 points (and SEQ animation can have just 2, like e.g. "all is lost", 6 in 1.SEQ), so I had to duplicate and jitter end points to make it work. Probably other spline type is used in DO, going to try...

Something is really wrong with the animation interpolation in DO.

By using the KEY data and simply interpolating between the keys with linear interpolation sometimes the animation doesn't reach the same positions as in DO. So either we got KEY data extraction wrong (don't think so) or DO devs did something crazy with the interpolation.

I've tried to apply overshooting when interpolating, i.e. instead of interpolating between two keys using 0.0-1.0 factor, interpolation is done in 0.0-1.X factor, i.e. 1.0-1.2. In effect this creates some exaggeration of the movement. Actually, this worked in some cases! And I've finally reached the same pose as in DO for e.g. 01 animation in 1.seq file. It doesn't work the same for all animations though.

Another very interesting observation. I've taken 0 animation from 1.seq (charge). It contains the same 03 commands

13 04 14 04
03 04 0A 0A
01 05 00 00
0A 03 00 00
03 00 0A 0A
02 00 00 00
08 00 00 00

notice, two 03 commands have the same 0A key! The only difference is in 04/00 byte (we know this somehow affects interpolation). Observing charge portrait animation in DO I can see that there slight movement in the end of the animation (though the position shoud be the same!).

So I did some testing. I've copied last 03 command and pasted it many times. Got following results in DO:
- animation is NOT static on these copied keys, I still see small movement (really small but noticeable)
- depending on 00/04 byte the movement is either constantly periodic or fading away slightly

And if I can somehow understand the fading case, I really don't get how can one get non fading movement between the same keys!! Even when using overshooting of some sort. It's like they have some sort of acceleration applied (which is also non-sense since the positions are the same). Another DO dark magic...

Excellent knowledge and yep we've certainly progressed Dark Omen along way since 2007, many thanks!

12 years of Dark Omen Fansite! (funded 5 Feb 2007)

Interestingly the following CTL commands are never used:

Code:

#24 add_global_r_i
#26 (called automatically each time the CTL script executes)
#27 (called when #26 set the true-flag)
#31 wait_unit_flag2_clear
#32 wait_unit_flag2_set
#37 wait_unit_flag3_set
#42 send_event_to_self_if_label_exists
#56
#57
#67
#68
#6f broadcast_event_to_enemies
#8a
#90 nop_90
#91 nop_91
#9a
#9e
#a0
#a4 find_enemy_simple
#a5 find_enemy_simple_visible
#a8 find_enemy_nth
#a9 find_enemy_nth_visble
#aa find_enemy_unittype_nth
#ab find_enemy_unittype_nth_2
#bb
#be
#c8
#c9 clear_last_event
#cb
#ec test_other_unit_r_eq_i
#f0

The following are only used in the tutorial (SPARE9):

Code:

#d9 test_user_action
#da ui_indicate
#db (this seems to check if you attack the training dummies)
#dc
#dd set_unit_r_direction
#de test_unit_at_node
#df test_unit_attacking
#e1 test_other_unit_flag3
#e2 test_unit_selected
#e3 test_any_spell_selected
#e4
#e5
#e6 test_mapmode
#e8
#e9
#ea test_sound_playing
#eb test_other_unit_flag1
#ed end_mission
#ee test_event_from_unit

Which means the following used opcodes have unknown purpose:

Code:

#14
#2b
#3c
#45
#46
#47
#48
#49
#4a
#4b
#4d
#4f
#50
#51
#5e
#5f
#60
#61
#62
#63
#64
#66
#6c
#7a
#7b
#7c
#7d
#7e
#7f
#80
#81
#83
#84
#85
#87
#88
#89
#8b
#8c
#8e
#8f
#95
#96
#9b
#9c
#a1
#ad
#b0
#b1
#bc
#c5
#c6
#ca
#cc
#d6
#db
#dc
#e4
#e5
#e8
#e9
#ef

Unknown OpCodes by popularity (funcs >= 100 are only counted once because they are always the same):

This means these are useful for map scripting in general.

Code:

406 #14
374 #3c
252 #d6
157 #50
145 #2b
101 #48
 86 #47
 78 #43
 60 #7e
 59 #9b
 45 #51
 34 #89
 29 #64
 26 #80
 24 #87
 15 #7f
 10 #e8
 10 #a1
 10 #5e
  9 #62
  8 #dc
  7 #81
  6 #7d
  6 #46
(rest omited)

When counting including all funcs >= 100 in all maps (shows which unknown opcodes the standard library uses alot)

Code:

990 #14
 813 #9b
 580 #2b
 536 #48
 461 #3c
 389 #50
 300 #5e
 282 #43
 270 #62
 252 #d6
 210 #81
 180 #7d
 180 #46
 176 #7e
 155 #a1
 150 #9c
 150 #8f
 150 #7a
 150 #6c
 150 #4d
 120 #ca
 120 #8e
 120 #8b
 120 #7b
  90 #c5
  90 #95
  90 #8c
  90 #60
  90 #4f
  90 #4a
  90 #49
  86 #47
  84 #80
  60 #bc
  60 #b0
  60 #ad
  60 #85
  60 #83
  60 #66
  60 #61
  60 #5f
  60 #4b
  60 #45
  45 #51
  34 #89
  30 #ef
  30 #cc
  30 #c6
  30 #b1
  30 #96
  30 #88
  30 #84
  30 #7c
  30 #63
  29 #64
  24 #87
  15 #7f
  10 #e8
   8 #ee
   8 #dc
   5 #db
   2 #e9
   2 #e5
   2 #e4

[during]

About 01 XX 00 00 command.

It's simply the delay command. The animation playback in DO will wait certain amount of time (controlled by the second byte XX, not sure the exact conversion rate though) before issuing commands that follow, i.e. everything is still executed in the linear fashion.

=====

Although, everything is not really that linear. E.g. 06 sequence (all is lost) looks like this

13 04 14 03
03 04 14 07
0A 02 00 00
01 05 00 00
05 00 00 00
02 00 00 00
08 00 00 00

05 command (close eyes) happen during the body/head animation (03 command). Not right away, but after some time (01 command).

=====

OK, I think I got it after twiddiling with SEQ files for couple of hours.

01 command actually isn't simple delay. It's a parallel command! Let me elaborate.

First, 01 command is dependent on 03 commands. 03 has its own time of animation. Basically all the animation happens between 03 commands. Let's call single 03 command execution time a segment. So 01 command starts parallel execution in the current segment (i.e. relative previous 03 command) after specified delay. But, 01 also has time! From my experiments if 01 time is less than its 03 time, then current segment's length is unchanged. However, if 01 time is larger than 03 time, then current segment is extended! It doesn't really makes sence to use this since it'll simply introduce pause in the animation (because 03 will already finish its job).

Second, 01 is used in conjunction with 05 and 0A commands. Its main job is to delay these commands relative to nearest 03 command (by specifying 01 time less than its 03 time). This will make eyes/mouth/sound play during the current animation segment.

Third, time scale of the 01 command seems to be the same as in 03 command.

Not sure if all this 100% correct, but at least it fits into my current tests without breaking anything.

BTW, for some reason 05 command is ignored if there's no 0A command in the sequence! At least this happened in my tests with battle SEQ files.