Version 0.1.23

Status
Not open for further replies.
Yes, when I wrote that, it was after seeing the generic_fm_smartlists function defined in SoundData/turkey.txt:

Code: 
; Heeeeeere's a useful one.  v1 and v2 are female and male hitlist ID's, respectively
; This track chooses the smartlist based on gender, picks a patch from that smartlist,
; plays it.  It also kills anything else the instance (person) is saying.
; New!  Now works for kids!  v3 = kid smartlist

generic_fm_smartlists
           ; Kill this actor's vocals
           seqgroup_kill Instance

           ; If it's male then redo it for male
           loadb v7 0           ;v7 = field ID (0 = gender)
           getsrcdatafield v7 arg1 v7   ;arg1 = source ID
           ; if gender is 0 then use v1 is correct (male)
           ifeq #_gotit
           ; otherwise set v1 to female list
           set v1 v2
           ; if gender == 1 then v1 is correct (female)
           loadb v6 1
           cmp v7 v6
           ifeq #_gotit
           ; it's a kid - set v1 to kid smartlist
           set v1 v3
_gotit
           ; v1 = smartlist id
           test v1
           ifeq #generic_fm_smartlists_end
           smart_setlist v1
           smart_choose v1
           set patch v1
           note_on v1
           wait_samp
generic_fm_smartlists_end
           end
]

"Actor" should mean an object on the lot; in this case, the generic_fm_smartlists function looks at the object, or "actor", that called the "Play sound event" SimAntics instruction to create this HIT thread. The comment at the top says "the instance (person)" (in this case, the object is expected to be a sim), and the comment "Kill this actor's vocals" tells us that "instance" means instance of an actor.

I am guessing that "vocals" means currently playing sounds. So perhaps "seqgroup_kill Instance" looks at all of the HIT threads created by this object instance, and looks at all sounds created by all of those threads, and "kills" (stops playing) those sounds. (It wouldn't make sense to kill all of the HIT threads created by the object, because there is still more code after the seqgroup_kill instruction in that function, so it wouldn't make sense immediately kill the thread after that instruction is executed.)

What a sequence group is a little open to interpretation.
 
Last edited:
We figured it out! :D

  • seqgroup_kill 0x45
  • Description: Kill an object's vocals, given a 1-byte object ID constant; the constant Instance=0 is a special constant that refers to the object ID of the object that created this HIT subroutine
 
What's interesting is that the seqgroup_kill instruction has a 1-byte operand, not 4 bytes. The question is, is this enough space to specify an object ID as an immediate constant? (Not a variable that holds a constant, but the constant itself, since it looks like "Instance" is a constant—it's not a track variable, because both Instance and arg0 assemble to the same byte 0x00.)

If you open up Pre-Alpha in NoNetwork mode, open Edith, add a bunch of new objects, and look at the "module inspector" dialog (which holds the list of all running objects on the lot), the lowest object ID is 1, and it counts up from that for each object you add to the lot. (You can confirm that the number to the right of the object name is the object ID by double-clicking the object name and looking at the "object id" attribute in the attributes pane on the right.)

So if the seqgroup_kill argument is a 1-byte imm8 constant, and 0 is a special constant that refers to the object ID of the object that created this HIT thread, then that must mean that the game has a limit of 255 objects that can run on the lot at the same time.

But I think I've gone past that trying to create a huge fire with a gigantic room filled with rugs, recliners, and plants... But I admit that I've never counted them.
 
I think the object limit is a short, and constant "0" always points to "this instance". The only time I've seen this used is with constant 0 in the sim hitlist subroutine, and there it's obviously used to kill the sim objects' (this instance) currently running sound threads.
 
Okay, I found a specific counterexample to my "the argument to seqgroup_kill is an imm8 for the object ID" theory:

Code: 
BINARY
[
station_rave
        loadb v1 #1
        seqgroup_kill #5
        set_loop
        loadl v1 #1588
        smart_setlist v1
        smart_choose v1
        smart_setlist v1
        smart_choose v1
        set patch v1
        note_on v1
        loadl v1 #250
        wait v1
        wait_samp
        loop
]

...

BINARY
[
RadioOff
     loadb v1 #1
     seqgroup_kill #5
     end
]

...

BINARY
[
PlayPatchAsMusic
     loadb v1 #1
     seqgroup_kill #5
_PlayPatchAsMusic
     set patch arg1
     note_on v1
     wait_samp
     loadb v2 #100
     wait v2
     jump #_PlayPatchAsMusic
     end
]
Obviously 5 can't be the object ID of a single radio, unless 5 is also a reserved object ID to mean "the radio" (which it's not; according to Edith, a "Portal - Pedestrian" has object ID 5 on the NoNetwork lot in Pre-Alpha). 0x05 happens to correspond to v1 in HIT, so, from the context of these functions, it's obvious that the argument to seqgroup_kill is a variable, so that this becomes "loadb v1 #1; seqgroup_kill v1; ...".

But unfortunately that makes "seqgroup_kill #0" become "seqgroup_kill arg0", which is very, very weird... But you know what's weirder... I've never seen a HIT subroutine refer to arg0... they always refer to arg1 and up, even though arg0 is defined in the HSM files together with the other track variables.

So I guess arg0 is a remnant of the past, and it should be replaced with "Instance".

But then what about Gender? Damn. :p I guess the subroutines are just always called with arg0=Instance, and sometimes arg1=Gender, and the developers made "Instance" and "Gender" as assembler directives, like "#define Instance arg0" and "#define Gender arg1", to make their code clearer because they used them so often. This makes the most sense.
 
Last edited:
RHY3756547 said:
The only time I've seen this used is with constant 0 in the sim hitlist subroutine, and there it's obviously used to kill the sim objects' (this instance) currently running sound threads.
Click to expand...

It is used when playing the pinball machine (amongst other things), and Fatbag and me reasoned it must be used to kill the running sounds, not the thread as this instruction is always followed by more code.
 
Yeah - just got it confused with the SimAntics primitive which does kill the threads.
 
Just fixed the city server. Hopefully (!!) authentication and encryption should be working now.
Here's the new client. It won't be released through the patcher as it isn't really a new version, more like a stability update.
I didn't test character creation yet, but please don't create new characters - at least not without deleting an old one first. The database will be cluttered!
I'm now running both login and city server from source, which should make it much easier to debug things when crashes occur :)
 
Welp.. client crashes when i open it...
I reinstalled PD.
I dragged all the contents of the zip into the TSOClient folder :/
 
Just fixed the city server. Hopefully (!!) authentication and encryption should be working now.
Click to expand...

Cant acess for now, "The key provided cannot be found on dictionary", hope a new version will released for fixing it??
 
Do you guys have the required XML files in your packingslips directory, such as "handgroups.xml", "cities.xml", "collections.xml" and "meshes.xml"?
 
Afr0 said:
Do you guys have the required XML files in your packingslips directory, such as "handgroups.xml", "cities.xml", "collections.xml" and "meshes.xml"?
Click to expand...

Yes i have those files, what is the usage of those xml?? Do you have updated it???
 
There's some MakeTrax stuff in ExpansionPack(5|6|7)/Sound/Sound.far in The Sims 1 that I've never noticed before.

defaultsyms.txt
maketrax.cfg
reserved.xml
sep5snds.txt
sep5snds.xml
sep5snds_userdata.txt
SimsGlobals.txt

Code: 
BINARY
[
RadioStationZydeco
         ; Kill any music track currently playing
         loadb v1 GroupMusic
         seqgroup_kill v1

         set_loop
       loadl v1 #20900
       smart_setlist v1     ;set main hitlist
       smart_choose v1       ;choose a sub-hitlist from that hitlist
       smart_setlist v1
         smart_choose v1     ;choose a patch from the sub-hitlist
         set patch v1
       ;;turn down volume to get rid of click
       ;loadl vol #0
         note_on v1
       ;; wait a bit and turn volume back up
       ;loadl v1 #80
       ;wait v1
       ;loadl vol #1024
         ; wait a bit before waiting for file to end
         loadl v1 #250
         wait v1
         wait_samp
         loop

And then I realized GroupMusic=1, GroupDialogMain=2, and GroupDialogOverlay=3 in the "Group" constants section of the wiki (that I made from Play Test's simsglobals.txt). Instance=0 happens to fit there. So Instance is probably the sequence group that refers to all sounds created by this HIT thread (I don't think it has to do with the object that created this HIT thread), GroupMusic is the sequence group that refers to the background music, and uh, I don't know what the others are.

But it turns out that the control groups are different from the sequence groups. The control groups are kGroupSfx=1, kGroupMusic=2, kGroupVox=3. (So GroupMusic is 1 and kGroupMusic is 2. Awesome...)

Edit: I am wrong. Instance is not a sequence group. I was actually right earlier.

Here is some code from SimsGlobals.txt:
Code: 
EQU Instance 1   ;arg1 - compiler bug won't let me set it to 'arg1'
EQU Gender 2   ;arg2 - compiler bug won't let me set it to 'arg2'

This explicitly confirms my "Instance and Gender are register aliases" theory. It couldn't be more explicit than this. However, The Sims 1 uses arg1 for Instance and arg2 for Gender, while The Sims Online uses arg0 for Instance and arg1 for Gender.

This explains why we see "seqgroup_kill #0" all over the place in newmain.hit in TSO, and "seqgroup_kill #1" in those same places (in the same subroutines) in simsgeneratedhitsource.hit in The Sims 1.

However, we also see:
Code: 
;----------------------------------------------------------------------------
; Track Sequence Groups

EQU GroupMusic 1
EQU GroupDialogMain 2
EQU GroupDialogOverlay 3

This explicitly tells us that these are all of the sequence groups. Since Instance=1 collides with GroupMusic (it collides with it in The Sims 1, but not in The Sims Online), "Instance" is not a sequence group; instead, it's a variable (arg1) that holds the ID of one of the above three sequence groups.

Okay, so it looks like we have an idea about what seqgroup_kill does, but I don't know what seqgroup_return does (which is also found in newmain.hit).
 
Last edited:
Status
Not open for further replies.
Back
Top