Update useSlave scenes

The goal of this MR was to update the useSlave scenes (as lightly as possible) so that they would use getSlave($AS) where $AS = $activeSlave.ID, per svorn's suggestion. Works well in testing. This avoids making updates to a copy of an object (the $activeSlave system we love to hate) that then goes out of sync, and should be a much better way of handling the situation.

I found two limitations, @svornost. One was <<setLocalPronouns getSlave($AS)>> does not work, but it wasn't an issue to leave that as $activeSlave since there was no updating being done. The other is that getSlave($AS).inflationType is not a valid drop in replacement for a block of SC text, it had to be <<= getSlave($AS).inflationType>>. You probably knew that, but just posting it here for anyone else that takes up the technique. I had to test each scene for places it was just printing "getSlave($AS).inflationType" instead of the value it contained.

It's probably not critical, but I added the update pronoun widget to the few passages that did not have it.

I also took this opportunity to move the files to a central location. One of them is a series of widgets in it's own file and a few are actually passages with their own control over the back button, so I moved each category to their own folder.

I tested both pregnancy and inflationType and found that they are correctly set as well with this MR.

changed title from Update use slaveScenes to Update useSlave scenes

changed the description

<<setLocalPronouns ...>> just calls <<run App.Utils.setLocalPronouns(...)>>, so you could just call it directly.

And yes, you can't call functions in SC text blocks. You can assign the return value to a local, though, if you prefer that.

I don't think we even need the pronoun check at all to be honest, since these are always called from interact and that sets pronouns itself. edit: ahh, seems some are used for fucktoy in main, so better to have the checks, yeah.

And yeah, a local would work, good point. Printing the function works fine too though it seems, so I'll probably just leave it.

added 1 commit

• cc5dc508 - dewidgetize fuckdoll scenes

Compare with previous version

Fixes broken fuckdoll scenes per Blank's observation in !6336 (merged). They were the only useSlave scenes that were in widgets, so I'm moving them into the same format as everything else and updating the few places that used them.

edit: and there is a block in surgeryDegredation that indicates agents should be treated as though they are not available for surgeries etc, so I'm gating that in the UI:

added 1 commit

• f58f4003 - gate agent from facilities

Compare with previous version

@svornost sorry to ping you, but I'm examining some other areas and came across this: <<set _slave = $activeSlave = $eventSlave>> I know it makes sense, transitive property and all, but I didn't think we could do that in SC?

edit: oh wait, this is the thing you wrote. I guess you like it then. and the _slave thing updates activeSlave, so you need AS Dump?

edit2: reason I'm asking is I'm looking at how hard it would be to phase out AS Dump altogether.

Yeah, that was me being lazy as hell because I'd already written a passage with _slave and then realized that I needed $activeSlave set properly too. Not really a pattern I recommend ;)

You don't know how badly I wish I could do that with a series of || checks off the same target.

added 1 commit

• 33c67d1b - more f class

Compare with previous version

added 1 commit

• 28b088de - update new files in SC blocks

Compare with previous version

merged

mentioned in commit d80bb124

I'm a tad bit worried about how this will scale with large slave arrays and how many times it gets called. May be valid to go for an inbetween like the special roles have and use a copy of the object just to run checks off of while making changes directly.

Why not use just $slaves[index]? Refresh my memory please.

I proposed slaves[AS] but @svornost preferred the function call, maybe he can explain. The function is stupid light though, I don't think scaling would be any issue whatsoever. In particular, we only need this system for SC passages. There's no reason to use $activeSlave in JS.

getSlave(slaveID) is just a double array lookup (it reduces to slaves[slaveIndices[slaveID]], but reads better). IDs are more stable than indices and therefore more suitable for passing between passages.