Sinks patch - Wash Dishes graphics glitch

Raeven

Well-Known Member
In-game: Sinks fail to reset graphics properly after washing dishes leaving a mound of soapy suds in the sink (Wash Hands will clear the issue away). This issue is purely cosmetic.
Behind the scenes: This is because the "wash dish core" BHAV's final animation (A2O-sink-washdishes-stop) was trying to use an event (Animation Tag == 0) that doesn't exist to trigger the graphics change.
Solution (Quick Fix): The graphics change was moved to an existing event.
SinksPatch_DishWash.jpg

Download Patch: http://www.woobsha.com/files/FreeSO/sinks_patch.zip
 
This might be more specific to the "expected events" function of animate sim, which may not be emulated correctly. I'll need to look into to it more.

I can include this patch with the client for now.
 
Ah! There's one more, then, that you may or may not want.
http://www.woobsha.com/files/FreeSO/sinkvacation_patch(partial).zip
It is for another sink (sinkvacation) which isn't included in the first zip because that sink has additional issues - such as not appearing in the buymode catalog.

This zip has the same graphic-fix piff along with other temporary files that allow me to use the sink in the game right now but you'll probably want to ignore since the X/Y coordinates (in the .spf.piff) will likely be 'off' later on, and the text file related to getting the sink into the buymode catalog. When I added the strings to the CTSS it apparently saved in the iff rather than updating the piff. So the txt file is my way of including them in the zip.
The "partial" part of the file name is just to remind me that extra stuff needed doing with this one.
 
This might be more specific to the "expected events" function of animate sim, which may not be emulated correctly.
When sorted perhaps this is will also allow the DJ Booth to turn on and off without a patch.There are 2 in the animation being used (using a remote control to turn the booth on) but the BHAV is written as if only one is expected causes the booth to turn itself off/on (first event) and then back on/off again (second event).

This occurs during the "Turn On Specific" BHAV tree's "A2O-tv1-surf" and "A2O-tv-sit-surf" animations. Instead of using separate BHAVS for turning on and turning off they went with a single BHAV "If it's off turn it on, if it's not off turn it off" so the double looping returns the booth to it's original state.
 
Last edited:
It's already mostly sorted, before it wasn't implemented at all completely breaking the bathtub and other objects. The issue there is that there ARE events, just not the ones it expected, so the "expected events" fallback that fires at the end of the animation did not fire any more. The case might be that it doesn't even care about the event tags in the animation and fires the expected amount anyways (or maybe even checks specifically for the existence of events with tag 0,1,2... and fires them if they are not present).
 
My experience is extremely limited (and pretty much amounts to poking iffpencil until interesting things happen in TS1). I was never able to view the animations' events directly (except for a few times when Peter was kind enough to convert some to plain text so I have a peek) so rely on the BHAVs to tell me what events are in any given animations and what the 'animations tag' value is. I also found that you could 'force' the number of events by entering that number into the fourth parameter/argument.
That is to say (Primitive 44) 5B 00 04 00 00 20 01 00
reads Animate Sim (id 91 from object events:1) {return event in Local Variable 4} {flags = 0, 1} in iffPencil
When you first brought up 'expected events' I assumed this was what you meant, but now it sounds like I was wrong.

Perception bias running amok, I guess, since I'd already decided that the TSO DJ booth must need a 1 entered there. I couldn't do that in Volcanic (that I could find), so the patch uploaded to another thread is a work around. But I've checked the TS1 DJ Booth, it does not have a "events:1" there and seems to work fine. I have clearly got all my wires crossed somewhere.

If I am understanding you now, though, it sounds like the temporary DJ Booth patch wont actually break anything later, but it (along with this sink one) wont be needed at all either. Very cool.
 
Volcanic has unusually limited support for the animate sim primitive, despite most of it being worked out (must have just forgot to keep it up to date). These issues are definitely caused by a VM bug somewhere, since these issues do not occur in TSO, it's just finding it that is the problem.

"events" is what I mean by expected events. I tested the behavior in TS1 a while back and it makes up some animation events to fire at the end. I haven't looked closely at the DJ booth or the sink to know what the script is with their expected events.
 
Back
Top