Jump to content

A generic scanner in sexout (code review please!)


Recommended Posts

I read your instructions for how to do this to other mods. Seems like a lot of work. What's the gain?

 

It's not really that much work, just looks that way.. ;) At this point with tryouts, it's just some copy/paste and search/replace. Once it's done you don't have to touch it ever again.

 

Gain wise, one scanner running means less CPU load or chance of conflicts, and scanner bugs can be fixed in one place and have the fixes automatically propagate to all mods using the scanner.

 

 

Link to comment

I read your instructions for how to do this to other mods. Seems like a lot of work. What's the gain?

 

It's not really that much work' date=' just looks that way.. ;) At this point with tryouts, it's just some copy/paste and search/replace. Once it's done you don't have to touch it ever again.

 

Gain wise, one scanner running means less CPU load or chance of conflicts, and scanner bugs can be fixed in one place and have the fixes automatically propagate to all mods using the scanner.

 

 

[/quote']

 

All right. Fiends (new direction will need constant scanner), Khans, Legion and Powder Gangers should be simple enough following the King's example, but I bet I mess up NCR. Going to get to work now.

 

I'm going to keep Working Girl a seperate entity for now, giving that it's more complicated than others.

 

 

Link to comment

I read your instructions for how to do this to other mods. Seems like a lot of work. What's the gain?

 

It's not really that much work' date=' just looks that way.. ;) At this point with tryouts, it's just some copy/paste and search/replace. Once it's done you don't have to touch it ever again.

 

Gain wise, one scanner running means less CPU load or chance of conflicts, and scanner bugs can be fixed in one place and have the fixes automatically propagate to all mods using the scanner.

 

 

[/quote']

 

All right. Fiends (new direction will need constant scanner), Khans, Legion and Powder Gangers should be simple enough following the King's example, but I bet I mess up NCR. Going to get to work now.

 

I'm going to keep Working Girl a seperate entity for now, giving that it's more complicated than others.

 

 

 

Sure, completely up to you. Once you're done/ready I can look at converting workinggirl. It shouldn't really be any more difficult than the rest. I left the scanner very generic, with no filtering on creatures or gender, to make this stuff easy. I really just replaces the "GetFirstRef" and "GetNextRef" calls that the normal scanners use, everything else remains basically the same.

 

I'm going to roll this version of Sexout into a real release now so people don't have to download the beta to use this functionality.

Link to comment

Quick question. I'm guessing once the scanner bits are removed, the Legion quest script should look like:

 

scn 00SexoutLegionQuestScript

short init
short approach
float fDelay


Begin GameMode

 if init == 0
   set init to 1
   set approach to 36
 endif

 ; lets put a little delay here
 set fDelay to fDelay + GetSecondsPassed
 if fDelay >= 5
   set fDelay to 0
 else
   return
 endif

 if FortEquipmentConfiscationQuest.bFortEquipmentStored == 0 && Player.GetInWorldspace TheFortWorld
   ; do not interrupt gate guard dialogue
   return
 endif
 ; Setup the sexout scanner to call us
 ;; Add our formlist
 if (0 > (ListGetFormIndex SexoutScannerListN SexoutKingsScanTargets))
   ListAddForm SexoutScannerListN SexoutKingsScanTargets
 endif

 ;; Add our spell
 if (0 > (ListGetFormIndex SexoutScannerListS SexoutKingsScanTrigger))
   ListAddForm SexoutScannerListS SexoutKingsScanTrigger
 endif
End

 

Or should the delay part be built into the scanner script?

Link to comment

That is the quest script which does the setup, you can get rid of everything in there except the scanner registration code. The rest of that stuff should be in the spell script you create, not the quest.

 

The delay isn't needed at all in either place, the new scanner has one in it itself. It will (should, have not tested extensively!) delay for 5 seconds whenever it detects a loading screen or sleep. I may have to remove the sleep check if it interferes with 'sleep rape' stuff.

 

The whole script should be:

scn 00SexoutLegionQuestScript

short init
short approach


Begin GameMode

 if init == 0
   set init to 1
   set approach to 36
 endif


 ; Setup the sexout scanner to call us
 ;; Add our formlist
 if (0 > (ListGetFormIndex SexoutScannerListN SexoutLegionScanTargets))
   ListAddForm SexoutScannerListN SexoutLegionScanTargets
 endif

 ;; Add our spell
 if (0 > (ListGetFormIndex SexoutScannerListS SexoutLegionScanTrigger))
   ListAddForm SexoutScannerListS SexoutLegionScanTrigger
 endif
End

 

In the new script you create for the spell, you want it to look like this:

if FortEquipmentConfiscationQuest.bFortEquipmentStored != 0 && Player.GetInWorldspace TheFortWorld
 ... rest of the spell stuff ...
endif

... code to clear the lists goes here ...

 

Note the change from '==' (is equal to) to '!=' (is NOT equal to) because you should clear the lists every time, no matter what. Sexout is going to fill them even if you don't want to run the spell, so if you don't clear them every time, they will have 'old' stuff in them later on.

 

Also note the changes of 'Kings' to 'Legion' -- though you probably already noticed that. ;)

 

I thought of having the scanner clear them itself before filling them, but that could cause problems in some odd cases.

Link to comment

So far, I have Legion, Khans and Powder Gangers "done." I put done in parenthesis because I won't believe they work until I see them work.

 

I'm guessing with an update of this magnitude a clean save is a requirement?

Link to comment

Acutally you shouldn't need a clean save for anything. There is a slight possibility you'll need one due to the Sexout.esm update, but I don't think so. I put a warning in the release notes just in case.

 

For the scanner changes alone, no clean save should be needed I don't think.

Link to comment

If a variable is set in the quest script, should it be left in the quest script? For example, in Fiends we have:

 

scn 00SexoutFiendsQuestScript

short init
short while
short endwhile
short approach
short callbackmode
short FiendsFriend
int bAlreadyTarget
int bCooldown
float fDelay
int bAbort
int nTmp
int nQuestStage

Begin GameMode

if callbackmode == 1
	set init to 0
elseif init == 0
	set init to 1
	set approach to 36
	set while to 0
	set endwhile to 1
endif

if FiendsFriend == 1
	setAlly PlayerFaction FiendsFactionNV
endif ...

Should the CallbackMode and FiendsFriend variables be moved into the scanner script or kept where they are?

Link to comment

They need to be in the quest script if you want to set them from somewhere else, like MCM.

 

You can't do "SexoutFiends.FiendsFriend" unless "SexoutFiends" is a quest -- meaning you can't do like "MyScannerSpell.FiendsFriend" to set that value.

 

If the variable is only used internally in the script, it can be moved to the spell.

Link to comment

Remember back when you fixed it because they would shoot at you instead of talking on any visit after the first? It's doing that again.

 

Going to redo the port to the new scanner more carefully this time. It's probably from me completely mangling the quest script.

Link to comment

I could definitely use a hand, I don't know what I'm doing to murder the quest script. For whatever reason, my attempts to port it over to the new scanner while changing it so the scanner runs everywhere (not just outside Vault 3) breaks the fixing you did awhile back.

 

This is my working copy of SexoutFiends. Only difference between it and the official thread copy is there's now a variable that makes fiends non-hostile the first time you fuck Motor-Runner. I'm uploading the original version with it's own scanner so you don't have to reverse engineer my mangling. I'd appreciate if you took a look.

Link to comment

Worked fine, here you are. Look it over and see if you can understand what I did vs. what you did, maybe I didn't explain things enough in the tutorial / howto.

 

EDIT:

Full version of the scripts I used:

 

Quest:

 

 

scn 00SexoutFiendsQuestScript

short init
short approach
short callbackmode
short FiendsFriend
int nQuestStage

Begin GameMode

if callbackmode == 1
	set init to 0
elseif init == 0
	set init to 1
	set approach to 36
endif

if SexoutFiends.FiendsFriend == 1
	setAlly PlayerFaction FiendsFactionNV
endif

 ; Register scanner
 ; Setup the sexout scanner to call us
 ;; Add our formlist
 if (0 > (ListGetFormIndex SexoutScannerListN SexoutFiendsScanTargets))
   ListAddForm SexoutScannerListN SexoutFiendsScanTargets
 endif

 ;; Add our spell
 if (0 > (ListGetFormIndex SexoutScannerListS SexoutFiendsScanTrigger))
   ListAddForm SexoutScannerListS SexoutFiendsScanTrigger
 endif

End

 

 

 

Spell:

 

 

scn SexoutFiendsScanTriggerSCRIPT

int init
int nCount
int nIndex
ref scanner
int bAlreadyTarget
int bCooldown
int bAbort
int nTmp

; loop label vars
int whileClear
int whileLoop

Begin ScriptEffectStart
 if (0 == init)
   ; Prevent this block from running more than once, I have seen it happen on occasion
   set init to 1

   ; Each while label var must have a different number.  In fact, you can just use
   ; numbers if you want with no vars for the Label and Goto statements.  Vars just
   ; make it easier to read.
   set whileClear to 1
   set whileLoop to 2

   ; Check for fiends quest status and player location
   if 10 < SexoutFiends.nQuestStage && 0 == playerREF.GetInCell vault3a && 0 == playerREF.GetInCell vault3b && 0 == playerRef.GetInCell vault3c
     set SexoutFiends.nQuestStage to 10
   endif

   ; Only do scan processing if quest stage is correct.
   if 30 <= SexoutFiends.nQuestStage
     ; Loop through the form list
     set nCount to ListGetCount SexoutFiendsScanTargets
     set nIndex to 0
     Label whileLoop
     if (nIndex < nCount)
       set scanner to ListGetNthForm SexoutFiendsScanTargets nIndex

       set bAlreadyTarget to (scanner.IsSpellTarget SexoutFiendsEffect)
       set bCooldown to (scanner.IsSpellTarget SexoutFiendsOldEffect)
       set bAbort to 0

       if scanner.IsEssential
         set bAbort to 1
       endif

       if scanner.GetDead
         set bAbort to 1
       endif

       if scanner.GetDisabled
         set bAbort to 1
       endif

       if scanner.GetCombatTarget
         set bAbort to 1
       endif

       if scanner.IsChild
         set bAbort to 1
       endif

       if scanner.GetPCIsSex Male
         set bAbort to 1
       endif

       if scanner.GetIsCreature
         set bAbort to 1
       endif

       if scanner.GetIsID V03MotorRunner
         set bAbort to 1
       endif

       if bAlreadyTarget
         set bAbort to 1
       endif

       if bCooldown
         set bAbort to 1
       endif

       if ((0 == bAbort) && (1 == (scanner.GetinFaction FiendsFactionNV)))
         scanner.CIOS SexoutFiendsEffect
       endif

       set nIndex to nIndex + 1
     endif
     ; End looping
   endif

   ; We're done, clear out the formlist.
   set nCount to ListGetCount SexoutFiendsScanTargets
   Label whileClear
   if (nCount > 0)
     ; Remove the first item
     ListRemoveNth SexoutFiendsScanTargets 0

     ; Get a new count to use in the if statement
     set nCount to ListGetCount SexoutFiendsScanTargets

     ; Go back to the if statement
     goto whileClear
   endif
 endif
End

Begin ScriptEffectUpdate
 if (1 == init)
   ; If we make it here, we are finished.  Dispel ourself
   RemoveMe
 endif
End

 

 

 

(EDIT: Removed download, quite stale at this point.)

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use