Difference between revisions of "0x006A"

From SimsWiki
Jump to: navigation, search
(Operands 9 - 16)
m (Operand 9: What? Digits?)
Line 184: Line 184:
 
<li><u>Not hurryable.</u> Also don't know.</li> </ol>
 
<li><u>Not hurryable.</u> Also don't know.</li> </ol>
  
Unfortunately, these flags aren't as simple as operand 3. Flip in temp 3 and Synch are in the expected places in the binary (ones and twos digits respectively),  but Anim resource is in the 16s digit, and Not hurryable is in the 32nds!  This leaves two flags in the middle that don't seem to do anything. I don't know if this is just an oversight in SimPE, or an unusual anomaly in the program itself. More testing would be appreciated.
+
Unfortunately, these flags aren't as simple as operand 3. Flip in temp 3 and Synch are in the expected places in the binary (bits one and two respectively),  but Anim resource is bit 16, and Not hurryable is bit 32!  This leaves two flags in the middle that don't seem to do anything. I don't know if this is just an oversight in SimPE, or an unusual anomaly in the program itself. More testing would be appreciated.
  
 
===Operand 10===
 
===Operand 10===

Revision as of 01:05, 19 July 2006

Contents

Animate Sim (0x006A)

The Basics

(note: This was written by someone with the original sims 2 ONLY. I have no idea if it's any different in the expansions.)

0x006A is the Animate Sim primitive BHAV. Any time a sim moves, it uses this function.

Animate Sim uses at least 12 of the 16 operands, and can use 4 (that I know of) variables from the calling BHAV as well. It must call an ANIM file, and can call another BHAV file as well. So yeah, it's fairly complex, and I'm not arrogant enough to say I understand how it works. These are some generalizations I've made from quite a few tests, and may not be correct. If they aren't, and you know it, there is an edit tab up at the top, calling you.

I used SimPE to find all this, by the way. The screenshot is from SimPE, too.

The Details

Like all BHAVs, Animate sim is called in it's own line, and is passed certain info from the operand list. Just for clarity, this is how I numbered the operands:


A lovely screenshot

Animate Sim basically works like this: When called, it finds the necessary animation (stored in an ANIM resource) by looking in a STR# (text list) file for the name of the animation, and finds the animation with the right name. Then it applies any changes made in the relevant operands to the animation, and plays it.

Okay: I am not going to cover the Operands in order, because it's too much of a pain (they all interrelate so much).

So, we'll start with

Operand 7

Operand 7 contains the last two digits of the instance number of the default STR# file. (the one it finds the ANIM name in)

Instance number 0x00000081 is the most commonly-used STR#. It contains all the names of the ANIMs that adults can perform relative to the object. At runtime, sims 2 looks for this STR# in the same group as the calling object; if not found there, it "fallsback" and looks in the object's semi-globals.

STR# instances 82 (ChildAnims), 89 (ToddlerAnims), 8A (TeenAnims), and 8B (ElderAnims) all work exactly the same way, and one needs to exist for every age group that can use the object.

Note: There doesn't need to be a call to Animate Sim for every age group. Animate Sim 
will find the appropriate STR# file for the age of the sim it applies to.

Instance number 0x00000080 APPARENTLY looks in globals. I don't know whether it actually looks for an STR# there, or if it just looks for the ANIM matching Operands 1 & 2.

Instance number 84 does something really weird, too. As far as I can tell, it fallsback all the way to globals, and reads the LocoAnims text file.

Any other instance number (including 00), if not found in the group, fallsback to the semiglobals, and looks in the ObjectAnims STR# 86. Obviously, object animations cannot apply to sims, and Animate Sim will throw an error and immediately stop whatever the sim was doing.


So: On to

Operands 2 & 1

Why 2 and 1? Why not 1 and 2? Because, like anything else in BHAVs, all 4 digit numbers are stored with the 16s and 1s first, then the 65536s and 256s (these are hexadecimal). Example: the hex number 1234 would be stored in two BHAVs as 34 12.

Anyways: Operands 2 & 1 can be two things. Either they define the line in the STR# file (defined in opcode 7) that has the desired animation's name, or they define the parameter that has the number that defines the line in the STR# file. (try saying that three times fast!)

Whether these numbers refer to the actual text line, or the parameter, depends on the next operand.

Operand 3

This is THE operand. It defines so much stuff it's easier if I make a graphic.


Opcode-3.png

Basically, anything highlighted in red is decided by this opcode.

Going through them one by one....

  1. Flipped. If flipped is false, the animation plays as normal. If flipped is true, the animation is, well, flipped, along a plane dividing the sim into left and right. The best example is the bed. If a sim gets in on one side, the animation plays normally. If the sim gets in on the other, the animation is flipped.
  2. Anim Speed in temp 2: Normally, the animation speed is contained in Operand 4 (more on this later). When this is true, however, the animation speed is called from temporary 0x0002. This is usually not useful if you're modding the original Maxis stuff, since temp 2 is often used for something else.
  3. [parameters 0x0000]. As mentioned in opcodes 2 & 1, this defines whether 2&1 refer to the literal number of the needed text line, or to the parameter that contains the text line.
  4. Interruptible. When true, the animation can be interrupted, and the BHAV continues on to the next line. I haven't seen this used much, probably because it only interrupts this one animation. If you cancel an action in the middle, and this is true, the animation will be stopped, but nothing else in the calling BHAV will be.
  5. Start at tag in temp 0. To be honest, I don't know. My only theory is that it might use the value in temp 0 as the starting frame of the animation. But this is just a hopeful guess; I really have no idea.
  6. Trans to idle. Same as above, I have no idea. I think it means the animation finishes by blending the end of the animation into the idle pose, but this is only a hopeful guess.
  7. No Blend Out. First, my conjectures on blending: when an animation is blended with the one before or after, Animate Sim treats them as one long animation, and meshes them together, producing a smoother overall movement. This seems to be supported by what I saw in the game, but keep in mind, I found out all this stuff by changing a file, then watching it in-game, so it could just be my eyes. But I think it is blending the animations.
  8. No Blend In. Same as above. Another note: I have seen a few animations (somewhere, I lost them) that looked like blending animations. For all I know, maybe these tags refer to them.


So that's what they do. How they're all contained is in flags, which use the binary number. In short, when this number is translated into binary, a 1 means true, a 0 means false. Using the above list, a 1 in the ones place means flipped is true. a 1 in the tens (or is it twos?) place means anim speed in temp 2 is true. And so on, throughout the list. Since that can be a bit confusing, here's a table of a few of the first values.

Operand Flipped Anim speed Parameter Interruptible
00 F F F F
01 T F F F
02 F T F F
03 T T F F
04 F F T F
05 T F T F
06 F T T F
07 T T T F
08 F F F T
09 T F F T
0A F T F T
0B T T F T
0C F F T T
0D T F T T
0E F T T T
0F T T T T

And so on, and so forth, throughout all the possible values from 00 to FF. And I know, the table is confusing too. Sorry.

Operand 4

This operand controls the speed of the animation. The default value is 20, but it can be set to anything between 01 and FF (00 results in an error). Values from 01 to 7F make the animation play forward, with the higher the number, the faster the animation. HOWEVER: VAlues above 7F (or from 80 to FF) make the animation run Backwards, with larger numbers making the animation slower. So 7F would make a fast, forward animation, and 80 would make a fast, backward animation. A normal speed backward animation would require a value of DF.

Operand 6 & 5

Another 4-digit hex number, this one specifies the event tree to run while the animation is playing. Anything you could run in a BHAV line, you can run here. If set to 0000, no event tree is run.

Operand 9

Operand 9 is like operand 3: it's several flags in one.

  1. Flip flag in temp 3 This doesn't say to flip the flag in temp 3, it's saying the flip flag (from operand 3) can be found in temp 3.
  2. Synch to last anim I presume this means to synchronize this animation with the previous one. Since most in-game objects that involve object-sim interactions have the object animation right before the sim animation, this makes sense.
  3. Use controlling object as anim source Don't know, to be honest.
  4. Not hurryable. Also don't know.

Unfortunately, these flags aren't as simple as operand 3. Flip in temp 3 and Synch are in the expected places in the binary (bits one and two respectively), but Anim resource is bit 16, and Not hurryable is bit 32! This leaves two flags in the middle that don't seem to do anything. I don't know if this is just an oversight in SimPE, or an unusual anomaly in the program itself. More testing would be appreciated.

Operand 10

Plain and simple, it defines the IK (inverse kinematic) object. IK objects, as far as I understand, deal with aligning sim animations to objects. For example: when a sim opens a fridge, an IK object deals with making the sims hand grab the handle. And that's about all I know.

Operands 12 & 11

Yes, yet another 4-digit hexadecimal number, dealing with the IK object identifier. Since I know almost nothing about IK objects, I know nothing about the identifiers.

Operand 13

Priority. 00 is low, 01 is medium, 02 is high. Exactly what the priorities do...?

Operands 8, 14, 15 & 16

As far as I can tell, these are all unused. I have a suspicion that operand 8 really does do something, and I've heard that it decides the location of the ANIM file, but I've never seen any change in the animations by changing this value. (and I have tested for ANIM locations)

Opcode 14 seems to be set to FF often, but once again, I've never seen any difference.

See also

Personal tools
Namespaces

Variants
Actions
Navigation
game select
Toolbox