Fallout New Vegas GECK & Scripting Help 101

[jaam]

Jaam, do you have any insight about why GetCallingScript returns 0 for quest stage/dialog result scripts? If it just returned the Quest refID or the dialog topic refID in those cases, that would be sweet.

 

I think I looked at it last time you raised the issue, and totally forgot the reason since then

 

I need to finish updating my FNV installation now that I have finished playing Wasteland 2 and I have a stack of debugging to do.

[prideslayer]

 

 

I was thinking, maybe down the line, we could have a sex act where one partner is sitting and the other is playing an animation.

In that case I think I'd just want to use refSurface and play a sexout sitting animation, to get around any vanilla sitting replacement anims and so on, so GetSitting would still return false.

 

 

The issue's still hypothetical of course, but way back when I had the damndest time trying to set an anim on a couch using the refsurface vars and eventually gave up. I wager this was due to the actual sitting surface of the couch being a sight lower than where the actors were set, and clipping with the back of it. Chairs will probably suffer the same fate. Although maybe it all depends on the nifs, combined with the specific anims, really.

 

The new system in the beta will help out once I'm finished with it. I now have fnSexoutInitSurfaceList...

 

  ; Pillory 150
  let SexoutNGAQ.animsZAZSurf[150] := ar_construct stringmap
  let SexoutNGAQ.animsZAZSurf[150]["VOffsetA"] := -20
  let SexoutNGAQ.animsZAZSurf[150]["VOffsetB"] := -20
  let SexoutNGAQ.animsZAZSurf[150]["VOffsetC"] := -20

At present to use it, the offsets must be in place, and the provided refSurface must match the anim that it is intended for. That will change going forward and eventually it will be possible to provide just the refSurface and have sexout pick a random animation that will work with it, with the correct offsets.

 

It's going to be tedious to build, especially to support non-surface animations on surfaces, but we already know that WRT the beds -- this is just "more", with tables, couches, etc where appropriate.

[prideslayer]

 

Jaam, do you have any insight about why GetCallingScript returns 0 for quest stage/dialog result scripts? If it just returned the Quest refID or the dialog topic refID in those cases, that would be sweet.

 

I think I looked at it last time you raised the issue, and totally forgot the reason since then

 

I need to finish updating my FNV installation now that I have finished playing Wasteland 2 and I have a stack of debugging to do.

 

No rush. Nobody has run into the bug I know is there yet.. probably because so few mods are using the UDF syntax.

[DoctaSax]

The new system in the beta will help out once I'm finished with it. I now have fnSexoutInitSurfaceList...

 

  ; Pillory 150
  let SexoutNGAQ.animsZAZSurf[150] := ar_construct stringmap
  let SexoutNGAQ.animsZAZSurf[150]["VOffsetA"] := -20
  let SexoutNGAQ.animsZAZSurf[150]["VOffsetB"] := -20
  let SexoutNGAQ.animsZAZSurf[150]["VOffsetC"] := -20

At present to use it, the offsets must be in place, and the provided refSurface must match the anim that it is intended for. That will change going forward and eventually it will be possible to provide just the refSurface and have sexout pick a random animation that will work with it, with the correct offsets.

 

It's going to be tedious to build, especially to support non-surface animations on surfaces, but we already know that WRT the beds -- this is just "more", with tables, couches, etc where appropriate.

 

Yeah, it's always been about the leg work of getting those numbers in the end.

Why not just go

let SexoutNGAQ.animsZAZSurf[150] := ar_map "VOffSetA"::-20, "VOffSetB"::-20, "VOffSetC"::-20

?

[prideslayer]

Well two reasons.

 

I want it to be easy for user submissions/contributions, and I think the "long way" is easier to grok. There are many more potential vars than just those, so the line can perhaps get quite long with entries "out of order".

 

Right now there are the standard six offsets [H,V]Offset[A,B,C], plus space reserved for [X,Y,Z]rot[A,B,C]. I'm not sure that anything else will ever be needed but 15 (worst case) would make for a "difficult" to scan and modify entry. I'll revisit it as people get more comfortable with it. If I run into script length issues, I'll just split up the UDF. It's only called once so performance isn't really a concern.

[DoctaSax]

Well two reasons.

 

That sounds sensible, 15 possible vars can definitely get cluttered.

 

[Odessa]

On RefSurface furniture, Loopy06 found that adding a collision marker over the surface stopped the clipping/misalignment. I started doing this using enable/disable in soliciting and it works a lot better. You can also refsurface an XMarker placed just above the furniture which is easier than trying to calculate offsets.

 

I do not think you can use PlaceAtMe to create collision markers dynamically, but I think MoveTo may work. If so it may be helpful for all sexout animations.

[D_ManXX2]

I have currently a mod i am working on actually it was very old mod i never finished but it's been so long, and was wondering how is the normal procedure to get the mod integrated with sexout without breaking the compatibility between new version when they are released ??

 

Let's say i make new animation and add them through my own mod, but that require changes to the original sexout.esm scripts with will possibly break any future additions that prideslayer will release or force me to redo great part of the mod if i go this way. What is the best way to proceed this way ??

[nyaalich]

Out of curiosity, why wouldn't you have them be added to SO for all mods to make use of?

[Loogie]

I have currently a mod i am working on actually it was very old mod i never finished but it's been so long, and was wondering how is the normal procedure to get the mod integrated with sexout without breaking the compatibility between new version when they are released ??

 

Let's say i make new animation and add them through my own mod, but that require changes to the original sexout.esm scripts with will possibly break any future additions that prideslayer will release or force me to redo great part of the mod if i go this way. What is the best way to proceed this way ??

 

I would make a separate .esp that adds then anims, then send that and the anim files to Prideslayer to put into Sexout.  Once they're in Sexout, then use them in the mod.

[D_ManXX2]

 

 

Out of curiosity, why wouldn't you have them be added to SO for all mods to make use of?

 

Because it allows me to release new stuff and at the same time allow normal players to play test with the animation instead of waiting till a new version of sexout is out. Right now the only for anyone to test animation is either as re placer instead of newer added directly to sexout system.

 

Right now i was thinking of just making an extra esp that actually edit sexout.esm and edit it in there that way the mod i work with has no reason to even touch the sexout.esm scripts. And when prideslayer updates the sexout.esm system i will just delete this extra esp and start over from there.

[Guest tomm434]

Any ideas on how to make player undetectable to particular actor. I'm doing cutscenes using A.J.'s method (http://www.loverslab.com/topic/24649-new-vegas-ingame-little-machinima-animation/) and if I move player close to actors they gree player, turn their head etc.  If I give them package with "Headtracking off" - they don't turn their head to each other and scene looks very lame.

[Guest]

headtracking off + forcing them to look at the other npc via script with Look?

[Guest tomm434]

No - clone turns body but doesn't turn it's head to an actor

[Guest]

Could be wrong of course, but I don't feel it's possible. I dug stuff about headtracking few weeks ago because I wanted the headtracking mod like in skyrim, but unforunately I didn't find anything to handle it (except the flag on the package and the look function)

 

However, if for some reason you must avoid a npc to look at the "camera"... your camera could temporary raise Sneak to <some big value>, crouch in sneak mode, maybe CIOS a stealthboy too... with some luck noone will notice the camera

[Guest tomm434]

I used your idea with look but now I spam look on player clone with headtracking ON. He looks right where he should. Thanks.

 

 

 

I have another issue. I have a nightkin who doesn't want to do "Use weapon" package. But he did. His AI procedure is stuck at  33 (Choose cast) ( He has weapon, he equips it, he has ammo, he has weapon in his own weapon list, he is not restrained.

 

Any ideas anyone?

 

 

HM HM looks lke he was in combat for some reason - I ticked "Continue during combat and now he shoots fine."

[Guest]

I had another idea for the headtracking. Place the "camera" just a bit more far away than the actor which requires the headtracking. I.e. you have actor A which needs to headtrack actor B, but instead it looks the camera, you place camera just <very small value> units more far than actor B, then tweak the headtrack max range via script so that it is == to the GetDistance between actor A and actor B. With some rounding, of course, some margin of error. And at the end of the cutscene you restore the original headtrack range

 

EDIT: oh well your actual solution probably is the best

[Guest]

I would like to build the name of an UDF to call on the fly.

 

Something like this:

Let sUDFName := "prefix" + $iCounter + "suffix"
Call sUDFName

so it will call a different UDF based by the actual value of iCounter

 

But I can't make it work. I enabled CO and it still doesn't parse that second line. I tried to add StringTo (Call $sUDFName), same result: "EXPECTED USER FUNCTION"... Is there a way to do that? I thought CO was making the trick

[DoctaSax]

The call function expects a form, not a string. When you declare a script's name, that string becomes the editorID, which in turn is morphed into a formID when the game loads.

You could park the UDFs in a formlist or array, and retrieve them from that though. That's how I pick my semen eval UDFs in spunk.

[Guest]

I can do it in a different way, using workarounds passing parameters etc.etc.

But still I would like to understand what you mean, I'm pretty curious about how to pass this kind of parameters with pre-constructed strings.

 

"You could park the UDFs in a formlist or array"

so you mean creating an array of strings, these strings are the names of the UDFs, and then I "Call arMyArray[number]"? or you mean something else I don't get?

[DoctaSax]

No, you create a formlist or array of forms, the actual UDF scripts.

When you call a udf in a script like

call someUDF

 

then "someUDF" is the editorID string. In-game this becomes a form. You could replace this with a ref var

let somerefvar := someUDF

call somerefvar

 

Therefor you can go retrieve that ref var from a formlist:

let somerefvar := ListGetNthForm someFormList iIndex

call somerefvar

 

or directly from an array

let somearray[iIndex] := someUDF

call somearray[iIndex]

[Guest]

that's pretty clear, thank you Doctasax.

[Guest]

This:

                Let antQuest.arAnimName[iCat][iCounter] := sAnimName

... spams errors in console, about Let which can't do that. Tried with StringTo on sAnimName, but it doesn't solve, I more think it is because it's a quest.array, while the Let would appreciate a local array...

 

Could someone script me the correct line to declare a temporary local array and assign to my real array, to see if it solves my problem? I'm afraid to make the contrary, to put null values of the temporary array inside the values of the real array...

 

OR tell me the reason why it spams errors, if you think it's not because it's a quest.array

[DoctaSax]

I think this is probably because the sub-array hasn't been initialized yet.

 

The basics are

let array[key] := ar_construct "array"

let array[key][subarraykey] := something

[Guest]

EDIT:

yes you were right, it wasn't initialized. Also I did a lot of mistakes with these multidimensional things, I will go back and start from scratch. Thank you