Fallout New Vegas GECK & Scripting Help 101

[prideslayer]

 

The main problem I have with tokens is their 'accidental' release into the wild if something goes wrong.

 

Figure of speech, or some other character randomly getting the token even though they shouldn't have?

 

Tokens are not meant to be interacted with or used like 'normal' inventory items. It happens from time to time though that they find their way into leveled lists, or a player will loot them from an npc, or a mod that takes everything from the player or an npc will move them into a container or another NPCs inventory (or the players).

 

When any of that happens, things break.

 

Now the second question then...

 

When I was doing my tries in pair animations, I create a M animation and a F animation.

Then, to trigger them, since I wasn't sure of what I was doing I tried two different approaches.

One was a simple playidle, the other one was additem (a fake item, so I suppose I should call it "tokenM" and "tokenF"), the M animation had GetItemCount tokenM as condition while the F animation had the GetItemCount tokenF.

Both cases had the same effect, with a big difference. Adding the token I had a lot of delay with consequence big de-sync between the two animations. Well, I was wondering why this should happen, aren't both cases supposed to run in the same way, in the same frame? Keep in mind I did a lot of tries, so it wasn't a casualty (as the common de-sync of big animations, it really seems a casualty for me).

Sexout itself uses this approach. Tokens are used to indicate which animation an actor should play via GetItemCount, however, the tokens are not scripted. Your performance problem was scripting those tokens. Imagine what happens if you ad 10,000 tokens to an actor and they all have a script on them? You're going to run your script 10,000 times. Even if you ensure that all the scripts after the first one instantly exit, that's still at least 2-3 lines of script.

 

If you're using a token as a counter, that's fine, you just better not script it unless you know exactly what you're doing. The dress/undress tokens in sexout are scripted, but an actor only ever has 2 (maybe 3, I forget) of them, maximum. You give them the first one and they undress. It watches for the second one to appear and if it does, redresses them and removes both. When the sex act says to not redress the actor, the first one is just removed and the second one is never added.

[A.J.]

I didn't think Sexout used the tokens approach. Is it checking GetItemCount too?

That's very strange. I didn't script anything else than a Gamemode quest script. My tokens were common items, not scripted, they were used only to satisfy the Condition I've written in the animation (GetItemCount TokenM or TokenF). But believe me the delay was very much more noticiable than invoking a simple playidle.

 

I've set a low delay on the script, because of the setpos, and it was doing something like this:

 

NPC1REF.additem TokenM

NPC2REF.additem TokenF

---jump on the next stage

Next stage:

setpos NPC1REF

setpos NPC2REF

Stick on this stage until KeyPressed

 

While the other script was simply:

NPC1REF.Playidle AnimM

NPC2REF.Playidle AnimF

---jump on the next stage

Next stage:

setpos NPC1REF

setpos NPC2REF

Stick on this stage until KeyPressed

 

Now I can assure you the playidle was almost never de-syncing my animation (about once every 5 tries, more noticiable if I was near, the only thing I think is because of headtracking), while the first one was almost always de-synced (at least 4 on 5 tries, it was very noticiable the fact they were starting in two different moments). So I figured that or the AddItem was slow, or the GetItemCount check was slow. I abandoned this solution for the simple playidle (I use a clone so it invokes animation without tfc etc.). I also tried invoking animations using a Travel Package with a specific idle, it was very slow, de-syncing too much.

 

That's why I'm wondering if there's some list that tells me what "slow" is and what "fast" is, or some logic so that I could understand better this. Oh, playsound is in the "slow" category, it's one of the few things I noticed...

 

Well, to explain something else because this all seems quite confusing... Using certain scripts, I have several problems regarding the whole "speed". When using an ENB, for example, some scripts refuse to work properly as if the engine simply can't do it. It's nice to see it: it doesn't work, then I press Shift-F12, it starts working perfectly. And viceversa. This is a real pity, because it would be very pretty for me using these scripts. I know some people solved that using other ways, but... they didn't want to tell me how, so I'm trying to figure a solution on my own.

[prideslayer]

Sexout uses tokens for counters, a token for position, and pickidle with conditions on the animations. For any given animation, I will add anywhere from 100 to 10,000 counter tokens.

 

I intend to ditch that and switch to playidle myself at some point, but it's not additem or getitemcount that is slow.

 

The only things that are generally slow are:

- Things that modify the 3D scene, like adding an NPC/creature/whatever.

- Zone changes (obviously)

- Floating point math operations and functions like division and cosine.

 

The floating point things aren't even *that* slow, they're lightning fast compared to the other two, they are just slow compared to integer operations.

[A.J.]

Oh if you want you could do the same try I did, really believe me if I tell you I found a very big difference in delay with the two approaches. Anyway, since "few times" is not "never", I gave up pairing animations because even playidle de-syncs sometimes, it's impossible doing some nice animation when they don't pair, it's... enervating.

 

*sob* it's bad understanding that all I have in mind isn't possible because of engine, just after little time I realized how many things were possible to do with modding... I'll try to focus, to figure if it's possible using a workaround for all my "use and abuse" of sin and cos functions. But I admit I wouldn't even know where to start.

[prideslayer]

I've noticed no such 'delays' doing it the way I am in sexout itself, have you? The animations are usually pretty close to in sync, at least, as close as I can get them at present. I will need more control over them via NVSE if I ever want them to be perfectly in sync, but they're close enough most of the time.

 

PlayIdle only works on the player when the UFO camera is on and right now I cannot check that it's on, though jaam as a fix for this coming in the next NVSE. That is the main thing that's kept me from switching to it.

 

Once I can ensure the UFO cam is on, I will switch to playidle and will be able to rely entirely on NX vars for the anim # tracking and usage. I will still be handing the tokens out for a while though because all the other mods that care about which anim # is playing (like SexoutPositioning) need them.

[prideslayer]

As for sin/cos, unless you're doing thousands of them every frame, I really don't see how they can be causing you problems.

 

Rule of thumb: When you're doing mod development, do it with the *least* amount of mods loaded and get it working that way first. That means severely curtailing your load order, removing/disabling ENB, etc. There is simply too much potential for conflict and you'll forever bang your head against the wall if you don't ensure your own code is working before you try to find conflicts.

[A.J.]

The only thing I can tell you about de-syncs is what also someone else confirmed me, I think it was DMannx I don't remember exactly the name. I de-sync only when an animation is over a certain amount of frames, around 600+. While I loaded and reloaded a lot of times to see if there was some pattern, some common denominator (and instead it was absolutely random, I did over a hundred of tries), I really only tried 3 couple animations: one was mine, around 1200 frames, another one was that kiss animation I've put here (around 400) and the third one was kindly given by DManx (don't remember the frames, but they were a lot), just to be sure to try something else than what I was creating on my own. The only one that was always syncing was the one at 400 frames. I also downloaded SO and I have placed a couple of random animations from there, but I didn't import on Blender so I wasn't really sure if they were smooth or not, they seemed smooth to my eyes, but it's hard to say when the movements are fast. When that user told me the same thing I noticed (for bigger animations), I really thought it was an engine limitation.

Anyway, the only thing I was sure was that while playidle was de-syncing only sometimes, tokens with GetItemCount or triggering a Travel Package were a complete bloodbath, really impossible to use them for me because of delay. Of course I could have done bad things in the script, but as you can see it was something very easy and plain, very few lines.

 

But if you really can sync them properly I'll be very very grateful if you tell me the trick!

 

The way I pair animations is without UFO cam, I usually invoke a clone of myself and use it, since I'm the camera. It's the kind of solution I'd love to stick with, for some kind of effects I really would like to achieve (even if I'm starting to think this is impossible too, because of sin and cos slowdown)

 

EDIT: just seen your new post. I don't use a lot of sin and cos, but it's the combination of things that slowdowns. Take 3 things: ENB, my script and Fraps to record. If you use two of them, it works. If you use the third, it doesn't work, either Fraps or ENB. Fact is if it's for machinima I really love both the things... ... ... but mainly, ENB is something very much used, I should at least try to do something that could be used by more people, or at least it's what I'd like to achieve.

[nyaalich]

 

TL;DR: is there somewhere a list that tells me if using some function is faster/slower than another one? the only thing I found in Beth guide is sin,cos etc. are slow functions, and I noticed it... but yes, I've never found anything else about other functions.

 

I accidentally found this.  http://forums.bethsoft.com/topic/987561-script-optimisation/  Unfortunately, the link to the the original Oblivion optimization link in the OP is gone.

 

I also wish that there was some resource of which cells were affected by the mods mods - as in adding buildings or modifying previously boarded up buildings.  Everyone knows that every modded item ever is in Doc Mitchell's house.  ; )

[DoctaSax]

 

PlayIdle only works on the player when the UFO camera is on and right now I cannot check that it's on, though jaam as a fix for this coming in the next NVSE. That is the main thing that's kept me from switching to it.

 

It does work when you're just in 3rd, y'know - provided you call it from a spell on the implied ref.

 

[A.J.]

An article about script optimization, and it's signed Cipscis! Woooo what a wonderful discover, thank you! *runs to read*

 

EDIT: I think I understand now. I learnt some things reading Cipscis tutorials. They were quite hard for me to be understood, and I was wondering myself why he was using this abstruse way of scripting. But now, reading for example how much a > is less efficient than a == makes me really wonder that he was writing things just to make them more efficient possible. I.E. have you ever seen how he scripts a staged timer? I was just starting with scripts, it took me a looong time to understand how he was doing that, it was everything but natural for me writing in that way, I still was making mistakes after I did some and I had problems in finding my own mistakes.

[nyaalich]

@A.J.:  His sub-menus gave me a fit too.  In the end, I lamed out and just had one variable with a bunch of values.  Got that working though.  : P

[prideslayer]

But if you really can sync them properly I'll be very very grateful if you tell me the trick!

I can't. The simple fact is, they are two different animations playing on two different actors. As far as the game engine is concerned, they are not related to each other in any way. If your system is lagging or being overloaded, they will be out of sync. Period. There is exactly one way around this right now, and it's a complete nightmare.

 

Which brings me to...

 

EDIT: just seen your new post. I don't use a lot of sin and cos, but it's the combination of things that slowdowns. Take 3 things: ENB, my script and Fraps to record. If you use two of them, it works. If you use the third, it doesn't work, either Fraps or ENB. Fact is if it's for machinima I really love both the things... ... ... but mainly, ENB is something very much used, I should at least try to do something that could be used by more people, or at least it's what I'd like to achieve.

Doing development and testing in the engine with ENB *or* FRAPS is a bad idea. Doing it with both is an absolutely terrible idea. Both of these things place an additional burden on the graphics system, which causes hiccups in the game engine. These hiccups *will* throw the animations out of sync because of what I described above.

 

The "nightmare solution" is to make one animation file that animates a single mesh that is also a combination of all the involved actors. This will always be in sync, no matter what. However using something like this with sexout would require massive rewrites of the code, as well as replacing every animation. Even if you do all this, all the animations will cause the "apparent" bodies to switch from the user installed body to whichever one your mesh used.

 

If that didn't make sense, imagine you created a new monster. it has two heads, four legs, four arms, etc. It is in fact two complete people with a single texture that covers them both, connected by an invisible segment. Since it's one creature playing one animation, it will always be in sync.

 

Right now that is simply the only way possible to absolutely ensure that the animations are in sync -- by effectively removing sync as an issue to start with.

 

It does work when you're just in 3rd, y'know - provided you call it from a spell on the implied ref.

As sexout stands right now, I can't rely on that method, because I don't have any control over who the spell is cast on. I would have to add another layer to check for the player and always cast the post-sanity-check spell on the player rather than on the initial spell target, and then I would have to put a check everywhere I do a playidle to determine if I should do "(implied.)playidle" or "ref.playidle".

 

I know it sounds like a simple solution, but at first blush, it looks a lot more complicated than simply ensuring the UFO cam is on first, and then treating all the actors basically the same.

[DoctaSax]

Lol, well, as you know me and playidle go way back, and so much stuff has been said in the past about what it can't do with the player (generally speaking), I feel compelled to say it ain't so   How you mean to apply it in sexout is obviously your choice.

[A.J.]

"nesting multiple conditions instead of using the "&&" operator is a good way to improve efficiency"

 

Oh god this is absolutely contrary to what I could ever think! I take twice the time to read a statement SO my computer will take twice the time to do it too, this is my logic! That's why I won't ever be able to deeply understand scripts...  *laughs*

 

The "nightmare solution" is to make one animation file that animates a single mesh that is also a combination of all the involved actors. This will always be in sync, no matter what. However using something like this with sexout would require massive rewrites of the code, as well as replacing every animation. Even if you do all this, all the animations will cause the "apparent" bodies to switch from the user installed body to whichever one your mesh used.
 

 

I like this monster and I really would love to make a try with this thing. It is something I thought, once, but I soon thought it wasn't possible. I mean, could you really bring ingame a skeleton which contains two single skeletons? ok ok now this could seem a big dumb thing but I really thought it wasn't possible... I always loved to add bones to skeletons, to animate other things etc. , but I always thought it wasn't possible and it was the reason why in Skyrim a wrong skeleton cause a CTD... oh of course you could tell me "well what about bnb skeleton then?" and I tell you "I... don't know... those don't seem bones to me, they are ... not green, they are gray..." and you could continue: "ok so what about Astymma skeleton? it has a lot of bones!", and me "well, this is something I really always wanted to ask to Astymma..."

 

I get your point about ENB and Fraps... can you believe my ENB in Skyrim drops framerate from 70 to 10? I'm wondering who was the one saying ENB reduces of 10%... maybe he wanted to say it reduces AT 10%...

 

Anyway, you're absolutely, completely right: I think a mod, no matter what it is, should be always tried with vanilla and I'll never go out from that creed. But this is a peculiar case unfortunately. If it's a mod that will pilot a camera, using Fraps and ENB is essential because it's a standard in machinima.

[prideslayer]

I don't know where you read the nesting thing you quoted, and I think the author probably just meant combining and not actually nesting. If you do that, and you put them in the right order, it can definitely make things faster. The computer is smart. If you want to check that A is true, and either B or C is true, and A is usually false, then "if (a && (b || c))" will be very fast because the computer can short-circuit the evaluation -- if a is false, it won't even look at the others.

 

As for the monster, you can put whatever crazy shit you want to in your skeleton. If you left all the bones on one 'side' named exactly the same thing as they currently are and ensured that one was facing the right way, it could even replace the default skeleton without problems. Which is good for you if you go down this path to madness, because otherwise you're going to have to make your monster a custom race. However because of the single-mesh issue your work is very much cut out for you. You're going to need an entirely new UV map for each model and so all new textures, and it gets even better. You'll need three different models just for 2p sex: MM, FF, and MF. You'll probably actually need two MF's; one for the M doing the fucking, one for the F doing the fucking. Move on to 3p animations and it gets that much more complicated; MMM, MMF, MFM, MFF, FMM, FMF, FFM, and FFF all need represented; that's 8 different models, 8 different textures, and 8 different animation files.

 

Now try to add futa/dickgirl support.. oops.. just tripled the work since anywhere an F is involved in those 8 you need a counterpart where one of them has dick+tits.

 

It's pure absurdity. I mentioned it because it is, in fact, the only way to entirely get rid of the sync problem. A single animation running on a single creature is the only kind of animation in this engine that will never have a sync issue.

 

If you're making machinma and you want to do it with in-sync animations in *this* engine with ENB, I have a term you should probably just come to terms with: hardware video capture. A Hauppauge Colossus is a good starter HD video capture card. I have one in my HTPC for DVRing cable TV without HDCP restrictions and it works great.

[A.J.]

Well it wasn't exactly for me, I'm thinking about a certain mod with some functions since a long time, but it seems it's not possible because of these limitations, that's sad. I already use some (very raw) tools I made for myself, but they too are affected by slowdowns like when I turn on ENB or Fraps. I wanted to see if I could do something better, maybe someone could have found it useful. What I really can't get is how certain mods are very sophisticated and they too use a lot of math, but still they work quite good. I tried to give a look but it's something definetely over my possibilities to understand them. The way they... check the nearby collisions shooting a fake projectile... I really can't get that all, is completely a different conception.

 

But... about that monster... you're right, it's a very big pain, I really wasn't thinking about re-doing the UV including both the bodies

[prideslayer]

There are a lot of subtleties when it comes to performance. I said earlier I doubt it's cosine and such that are really you're problem there, it's probably something must simpler but non-obvious.

 

Have you checked your slowdowns if you turn the resolution down? I know full resolution HD is all the rage, but you don't really need that high a resolution for machinma. A high-resolution DVD is only 720x480, barely higher than standard-def TV. 800x600, 1024x768, and 1280x1024 were very standard gaming resolutions "back in the day."

 

I bet ENB (and I know firsthand, Fraps) will work much better at a lower res.

[t3589]

Long time caller, first time listener.  I'm at a hurdle I can't seem to get around in my experimentation.

 

- While playidle is running on PC

- While UFO cam.

- Unequip article of PC clothing.

- Equipped on the article of clothing then returns false.

- But no update to changes in the body occur (clothing still 'appears' equipped).

 

Unless I toggle tfc off, then back on, and pull the cam back out every time a clothing change occurs.  Then the clothing changes display.  My question is:  Is there any way to update the body in flight, other than tfc?

[prideslayer]

That is, unfortunately, absolutely normal for the engine with regard to the player.

 

The UFO camera being on simply disables a lot of display update stuff.

[nyaalich]

Anyone have any ideas about finding out if the PC is in a town?  Example:  are you in the Goodsprings cell of the WastelandNV worldspace?

 

GetInCell is only for interior cells, so that's a no-go, and from what I can tell, you can't add cells to a form list.  You certainly can't drag and drop them anyway.  : P  Haven't tried scripting to add it as that I've wanted to minimize head to desk for a bit.

 

Hare-brained ideas:

• Token (YAY TOKENS!):  Create a specific token and add it to exterior town cells.  Do a ref walk for the first hit.  If so, set IsInTown to 1.
  • Cons:  Refwalking is intensive, isn't it?  Also, I don't think that there's a standard size for exterior cells.  No idea if it could yield false positives on other exterior cells with enemies due to the radius.  My Google-Fu was inconclusive. 
• Dead, Tiny, Invisible NPCs:  Like the token, but add a dead, tiny, invisible NPCs underground to towns.  If player.GetInSameCell DeadNPC, set IsInTown to 1.
  • Cons:  Um, adding ~10 or more dead, tiny, invisible NPCs that will make people go "WTF?!" when no-clipping?

 

Any other ideas/suggestions?  This would definitely be useful for me for companion awareness, and it might also be useful for T3589 so that I can stop bringing odd/funny companion behavior demi-bugs to him.

[prideslayer]

Oh blimey.

 

You know there's an easier way... GetDistance.

 

Pick a landmark in each city/neighborhood, put them all in a formlist or array. Loop through them. Whichever one you're closest to is the one the player might be in -- then check the actual value to make sure they're not just 100 miles out in the middle of nowhere.

[nyaalich]

nyaallich.CIOS BlameTheLackOfDocumentationE

 

EDIT:  I didn't think of checking X-markers (obviously).  I nixed the living actor idea in the first place due to the possibility of kill everything players.

[t3589]

nyaallich.CIOS BlameTheLackOfDocumentation

 

You can blame me.  I knew about this but had forgotten all about it until prides post.  No I wasn't keeping it secret so I wouldn't have to implement it! lol

 

[nyaalich]

You can blame me.  I knew about this but had forgotten all about it until prides post.  No I wasn't keeping it secret so I wouldn't have to implement it! lol

I would have been/ am okay with you not implementing it.  Withholding esoteric secrets on making the ill-tamed engine do what you need it to do = for shame!

[prideslayer]

You could use placed markers if you like but that would involve a lot of cell edits in the mod, and so, potential conflicts.

 

Another solution would be to (manually-ish) record the X/Y coordinates of the town centers and a max-distance #, and do a normal distance calculation between them and the subject (i.e. pythagoras). If the distance is <= max distance, they are in that 'place'.

 

This is a lot simpler than it might sound, and will work no matter what modifications mods make to the world, short of actually moving an entire settlement. The 'hardest' part will be wandering around getting the x/y coordinates of the centers.

 

If you do use getdistance, make sure you call it as "object.getdistance player" and not "player.getdistance object." They should be exactly the same, but in oblivion at least, the second one is not reliable if they two are in different cells.