Fallout New Vegas GECK & Scripting Help 101

[thepineapple]

 

GetPackageTargetRef if memory serves.

 

 

Geck powerUp doesn't seem to recognise this function. What do I need to install to use it?

[Guest]

mmmh me too I didn't find anything like that on nvse

[t3589]

Maybe he meant?

ref.GetPackageTarget

[Guest]

Maybe he meant?

ref.GetPackageTarget

 

Doesn't return the target of the package and not who's executing it? :-O

[jaam]

Yes sorry, I did not understand the question properly (and I did meant GetPackageTarget, yes). In your case you can only use GetSelf, I hope it would work.

[pepertje]

I'm having a bit of trouble here:

I have a Stress mod in the makings, and I was hoping I could let sex factor in without requiring Sexout to be a master. I looked at the buildref, and I have it all covered up to the point where I want to check for the variables stored in the SexoutNG main script.

 

What I have right now:

 

;Sexout

int SexoutESM

int iSexoutQuest

ref SexoutQuest

Begin GameMode

	if IsModLoaded "Sexout.esm"
		set SexoutESM to GetModIndex "Sexout.esm"
		set iSexoutQuest to 019333
		set SexoutQuest to BuildRef SexoutESM iSexoutQuest
	endif

end

;Reduce Stress if player is having sex

short HavingSex

Begin GameMode

	if SexoutQuest.ActorA==playerref || SexoutQuest.ActorB==playerref || SexoutQuest.ActorC==playerref
	if HavingSex==0
		set Stress to Stress - 7500
		set HavingSex to 1
	endif
	endif

	if HavingSex==1
	if SexoutQuest.ActorA!=playerref && SexoutQuest.ActorB!=playerref && SexoutQuest.ActorC!=playerref
		set HavingSex to 0
	endif
	endif

end

 

 

If anyone knows if I can call upon the variables stored inside the script, please let me know.

[DoctaSax]

I'd seriously advise against using the quest variables, using that to grab or set intel for sexout acts hasn't been done in a couple of years now.
Instead, just go with the fnSexoutActorInUse UDF, which you can buildref as well and then call.

 

let rUDF := buildref whatever the converted formid is

let HavingSex := call rUDF playerref

 

[Guest]

Some time ago I did a small ESP to test timing.

I introduced 5 quests and a spell.

The quests had a difference delay (0.1 - 0.01 - 0.0001)

The fourth and the fifth quest had 1 and 99 of priority

The spell had both a GameMode and a ScripfEffectUpdate block.

 

Some results were expected, some weren't:

- I know priority is used in dialogues for the position of the line, but I always thought that priority, when scripts are involved (i.e quests and perks) was deciding the order of execution of that script inside the same frame. Instead this test denied it: with 1 or 99 priority, the order wasn't changing at all, and the quest with higher ID was executed before (and I also thought the contrary, like lower IDs were executing before)

- The other values were more or less expected: inside the same frame, it was first executing the spell, then the 0.0001 delay, then the 0.01 delay; the 0.1 was executed every 6 frames (running at 60 fps)

- No timing difference at all between a GameMode and a Effect block

[Swyke]

 

 

Some time ago I did a small ESP to test timing.

I introduced 5 quests and a spell.

The quests had a difference delay (0.1 - 0.01 - 0.0001)

The fourth and the fifth quest had 1 and 99 of priority

The spell had both a GameMode and a ScripfEffectUpdate block.

 

Some results were expected, some weren't:

- I know priority is used in dialogues for the position of the line, but I always thought that priority, when scripts are involved (i.e quests and perks) was deciding the order of execution of that script inside the same frame. Instead this test denied it: with 1 or 99 priority, the order wasn't changing at all, and the quest with higher ID was executed before (and I also thought the contrary, like lower IDs were executing before)

- The other values were more or less expected: inside the same frame, it was first executing the spell, then the 0.0001 delay, then the 0.01 delay; the 0.1 was executed every 6 frames (running at 60 fps)

- No timing difference at all between a GameMode and a Effect block

 

Very interesting, AJ! If I just had the time to make such experiments with the GECK.

 

 

 

... but why I post now:

 

In one of my few occassions to keep on working on my mods I tried to make a little 'cutscene', where two NPCs have a conversation the courier has to follow. But it wasn't very sucsessful. I followed the instructions from the GECK page to make a conversation between two or more NPCs.

But ... as I have no voices the subtitels have to be switched on and if you have that sometimes it is still hard to read them, and at least it doesn't look loke a 'cutsceene'.

I thought I had found more informations about making such things but this time google didn't help me.

 

So maybe someone can help me or has an advice where I can find something similiar where I can look into and maybe I could 'borrow' some solutions.

 

The thing I want to make:

 

The courier lies knocked down on the floor and has to listen to a conversation between two NPCs. Yes! Thats all! It would be nice if the courier could be forced to look at the NPC who is actually speaking, and it would be nice if the NPCs would look at each other, maybe sometimes look at the courier in the moment they are speaking about him/her. And at last it would be great if the one who is playing the mod had enough time and a good contrast to read the conversation. And maybe it would be better to get this conversation not as a 'conversation' but as the usual 'topic' style, so you could click through the conversation the way you do it with a common topic.

 

Well, anybody here who knows how to make this?

 

Thank you very much!

[Guest]

The way to build a conversation as it's explained on the wiky isn't bad, it usually works. Then there are a couple of more tricks that could help, like SayToDone, but yeah the problem with subtitles will remain, but what can you do against that? the only solution would be voicing them.

 

 

It would be nice if the courier could be forced to look at the NPC who is actually speaking, and it would be nice if the NPCs would look at each other, maybe sometimes look at the courier in the moment they are speaking about him/her.

The way I do this is different, I saw that in Beyond Boulder Dome and used for my mod too. NPCs are not conversating, they still will talk with the player, but referring to each other (so it's like if they are conversating). To explain better... imagine a npc on a edge of a room, and another one on the other edge. You Player arrive more or less in the middle of them, the first one will start talking to you, your camera will force you to look at him, he is looking at you but since the other npc is on the opposite, you could even think that he is looking at the other npc. After he speaks his line, the dialogue has a Goodbye flagged, and as result script there's a SecondNPCREF.StartConversation Player NextTopic, so at that point your camera will make a 180 degrees spin and will force to look the other npc, which will talk to you but still it would be like if he is talking to the other npc, etc.etc.

Hope you can get what I mean, or I'll try explain again. This method's very easy and works flawless. However, you can make in different ways, of course, both with animations (your player will look at the one who is speaking because you are calling a specific animation on the player) or via script (you turn your head using GetHeadingAngle, and then SetAngle X to change the vertical angle).

 

 

[t3589]

Why not just turn on subs when you want and put them back the way you found them when done?

[Swyke]

The way to build a conversation as it's explained on the wiky isn't bad, it usually works. Then there are a couple of more tricks that could help, like SayToDone, but yeah the problem with subtitles will remain, but what can you do against that? the only solution would be voicing them.

 

 

It would be nice if the courier could be forced to look at the NPC who is actually speaking, and it would be nice if the NPCs would look at each other, maybe sometimes look at the courier in the moment they are speaking about him/her.

The way I do this is different, I saw that in Beyond Boulder Dome and used for my mod too. NPCs are not conversating, they still will talk with the player, but referring to each other (so it's like if they are conversating). To explain better... imagine a npc on a edge of a room, and another one on the other edge. You Player arrive more or less in the middle of them, the first one will start talking to you, your camera will force you to look at him, he is looking at you but since the other npc is on the opposite, you could even think that he is looking at the other npc. After he speaks his line, the dialogue has a Goodbye flagged, and as result script there's a SecondNPCREF.StartConversation Player NextTopic, so at that point your camera will make a 180 degrees spin and will force to look the other npc, which will talk to you but still it would be like if he is talking to the other npc, etc.etc.

Hope you can get what I mean, or I'll try explain again. This method's very easy and works flawless. However, you can make in different ways, of course, both with animations (your player will look at the one who is speaking because you are calling a specific animation on the player) or via script (you turn your head using GetHeadingAngle, and then SetAngle X to change the vertical angle).

 

Wow! I think that is exactly what I was searching for! Thank you A.J. Thank you, very much!

 

[Swyke]

Why not just turn on subs when you want and put them back the way you found them when done?

 

Sometimes it hard to read the subtitles. Depending on the landscape (background), the transparency and the colour of the hud. And at least the second the mod creator can't control. So, if you want the player of the game to read a conversation it would be better with a background like the usual topics have. And as A.J's suggested solution uses topics you have the background ... and the possibility to click through the conversation.

 

[Guest]

 

And as A.J's suggested solution uses topics you have the background ... and the possibility to click through the conversation.

 

Another nice positive feature is that it requires time to make the whole thing working, like triggering the goodbye and spinning the camera. As result, there's more delay to read subtitles. If you like me can't live without subtitles (due to not understanding and speaking spoken english) you know how annoying is when you don't have enough time to read them...

 

Good R.J. Helms, he was a very good inspiration for me. His quests are amazing. Long life to R.J.Helms

[nkAlex]

Hey all.
Is there a way to fire an event or any other possibility to trigger a script every time the player hires or fires a companion? The obvious way is to store a previous list of companions in an array_var and regularly compare it to GetTeammates, but running a function which compares 2 arrays between each other every X seconds when it may actually be never needed at all seems like a little bit of an overkill performance wise...

[Guest]

If you can't find anything better, the first thing that comes in mind is something like this, which executes the code every end of a dialogue

Begin MenuMode 1009
   Let bIspokeWithSomeone := 1
End

Begin GameMode
   ...
   if bIspokeWithSomeone 
      Let bIspokeWithSomeone := 0
      ; compare ar_sizes
      ; if ar_size is different >>> someone new was hired >>> do the rest of the code
   endif
...
End

[nkAlex]

If you can't find anything better, the first thing that comes in mind is something like this, which executes the code every end of a dialogue

Hmm, seems like a way to do it, thanks! Although will not fire if some (3rd party?) companion is added/removed by a script, or is auto-fired on reaching wait limit...

[Guest]

 

If you can't find anything better, the first thing that comes in mind is something like this, which executes the code every end of a dialogue

Hmm, seems like a way to do it, thanks! Although will not fire if some (3rd party?) companion is added/removed by a script, or is auto-fired on reaching wait limit...

 

 

No, but you can't have everything

The auto-fire could not be a problem on itself, everything which is vanilla could be studied and scripted properly. I.e. they set those umanoid /non umanoid variables, you could check these instead, but just to make an example. In my opinion the real problem are those external factors (=mods) where you can't really foresee the behaviours, how they were modded and what they do. If you want to be sure, I still believe the best would be a gamemode on Default quest delay, even if like you say 99% of times that script is unuseful, there are far too many external factors that could influence these kinds of relationships. At that point, I would try to focus on reducing the most I can the operations every <default time> seconds to compare the arrays, i.e. I wouldn't really need to compare the elements of the arrays but only the size for example, pretty sure that an operation like ar_size is unpercettible under a point of view of performances.

[nkAlex]

No, but you can't have everything

The auto-fire could not be a problem on itself, everything which is vanilla could be studied and scripted properly. I.e. they set those umanoid /non umanoid variables, you could check these instead, but just to make an example. In my opinion the real problem are those external factors (=mods) where you can't really foresee the behaviours, how they were modded and what they do. If you want to be sure, I still believe the best would be a gamemode on Default quest delay, even if like you say 99% of times that script is unuseful, there are far too many external factors that could influence these kinds of relationships. At that point, I would try to focus on reducing the most I can the operations every <default time> seconds to compare the arrays, i.e. I wouldn't really need to compare the elements of the arrays but only the size for example, pretty sure that an operation like ar_size is unpercettible under a point of view of performances.

Yeah, vanilla companions shouldn't be a problem at all, I'm mostly concerned about 3rd party ones. The best way would be to fire an event on every SetPlayerTeammate call, but I guess there is no way to do that. For now I made it this way:

• A separate quest with a high frequency "monitors" last opened menu state (i.e. just sets an int to current MenuMode value and stores it as a quest variable).
• The companion quest is running with default frequency and updates arrays on following conditions:

• on first run;
• when the game is loaded/restarted;
• in case last opened menu (i.e. quest #1 variable) is 1001 (Message), 1009 (Dialog), 1012 (Sleep/Wait), 1013 (Pause) or 1075 (Companion wheel), the variable is then reset to 0;
• each time a game day (or more) passes — to handle scripts based on wait time.

I think that pretty much should cover most of it, unless there is some really complicated or weird logic involved. In any case, you can just force an update by triggering Main menu

Unfortunately, just comparing array size won't be enough since you can easily fire a companion and hire a new one pretty quickly. And the mod is also supposed to store "former companions" in a separate array.

[Guest]

 

Unfortunately, just comparing array size won't be enough since you can easily fire a companion and hire a new one pretty quickly. And the mod is also supposed to store "former companions" in a separate array.

 

It wouldn't be a big problem, since the dialogue would trigger and you would compare the arrays anyway. I was thinking that comparing the size would be only for extra events in game mode that you can't expect.

[nkAlex]

It wouldn't be a big problem, since the dialogue would trigger and you would compare the arrays anyway.

...unless somebody adds them via console

[Guest]

You can add the console to the menumode list of exceptions you did. But console shouldn't be considered as exception by mods, in my opinion: those who use a console must take the responsibility of their actions

[nkAlex]

Well, anyhow, that's more or less sorted out by now. There's another thing I'm now stuck with: I just wrote a neat paginator function for MessageBoxEx, i.e. it takes in an array of elements and splits them into a number ten-or-less-itemed message box menus with page counter and next/previous/cancel buttons on every appropriate page... and now instead of using it nicely like a function returning a value I'll have to stuck it somehow into a token because I have to listen to GetButtonPressed, which has to be run from GameMode block repeatedly... Grr, stupid GECK! I love C#...

[Guest]

yes I find it a pretty dumb function, it seems it returns a correct value only the first time. This big limit allows it to be used only in those very specific cases like triggering a menu in gamemode, so today 90% of the times I abandoned those types of menus in favor of other solutions

[nkAlex]

Well, I know a thing or two about programming in general, but GECK is mostly a whole new thing to me (the last time I've opened it was somewhere around the time FNV was released), so it is kinda frustrating to get stuck in completely unexpected places because of such limitations.

Is there another way to create menus? Or are you talking about completely another way, like terminals?

Also, I completely don't get it — just why, why did they do unresizable windows for most information heavy features, like dialogues? Seriously, I've got two large (30" and 24") monitors and I have to work inside a postmark-sized window, this is ridiculous. This is apart from it being extreeemely slow...