Hello everybody.

I'm new to the modding community here at Fallout, my experience is pretty much null with GECK though I have some experience with the Dragon Age mod kits and a huge programming background.

Currently I've run into a problem where I don't really know how to find the script or global that controls the hacking minigame for Fallout New Vegas. Is there even a script or anything?

In addition, I was wondering how I might make a script that would launch a multiple choice dialogue when any locked terminal is interacted with.

Thanks, everybody.

You would have to locate the script that is activated whenever you activate a computer terminal and modify it to bring up a menu prior to activating the hack or whatever medium you prefer. Don't see any issues with it though I'm of no help on this right now. Currently dealing with an issue that my geck won't let me save any scripts I create >_> so need to figure out what is up with that.
I'll take a look and see if I can locate it for you but no promises.

Shiny. I was actually looking through the script browser but I feel like I'm doing something wrong because all of the scripts look quest-related. Maybe I'll take a second gander because it isn't 3 AM this time.

Don't mess around with scripts that activate when you activate any console. There aren't any, so far as I Know.

What you want to do can be done via Perks, though. Specifically, in the Perk Entry go to 'Entry Point->Activate->Add Activate Choice' and you can add a menu option for when you interact with a terminal. Make it so it only happens with terminals by going to Target->New->GetIsObjectType->Function Parameters->Terminal.

another method I found would be to create your own script and add it in manually as a script activated with each terminal. Don't know what you plan to do with it so not sure if this is a worthwhile concept. You can view the different computer terminals in world object -> terminal in the geck and some of the terminals have additional scripts that activate prior to activating the system. You could work around it to form your window and choose to hack the console after that but you'd have to impliment your script into each one independantly (far from efficient). Haven't found anything that could help with overwriting all comp activation at once though. doubt I'll find it through this method in fact.

The physical interaction with terminals is AFAIK hard coded.

To launch a menu from a terminal, a simple script attached to the terminal with an OnActivate block would do. If you want to launch a menu from a button option on the screen, use the script box when setting up said button option.

ShowMessage IIRC is the function you want.

Adding a script to all terminals is a horrible idea. Just make an activation perk - it's a hell of a lot cleaner.

True. I misread that "any locked terminal" to be "a locked terminal".

I'm attempting to make a mod that'll give a player an 'auto-hack' chance based on minimum skill requirements (With higher chances of success depending on the surplus skill amount)

Which would pretty much be done by giving the player a menu when they activate any locked terminal.

In addition, what do I need to do to get the perk added from game start? Do I need to hook it to some initialization script at the beginning of the game that already exists or is there an option in the perk menu I see?

Make a new quest, set that quest to begin at game start, and add the AddPerk command to that quest's script (along with a DoOnce check so it only happens one time, then shuts down the quest).

Ahah. Gotcha. Alright, I think I've got it now. Just need to hammer out some bugs.

Not related, but how would you get a player's skill value? o.o; I can't find a function for that.

Believe it or not I figured stuff out.

For some reason it won't let me save this file. Is it not compiling?

If so, do you guys see anything wrong with it?

scn AutoHackTerminal	; Defining all variables used for this code.	short Choice	short Hack_Outcome	int RandVal	ref rTerminal	set rTerminal to GetContainerBegin OnActivate	; The message box for the choice between hacking methods.		MessageBox "" "Normal Hack" "Auto-Attempt Hack" 		set Choice to GetButtonPressed	  	; Main code		if Choice == 1		; The code to perform the autohack.				set RandVal to (1 + GetRandomPercent * (rTerminal.GetLockLevel * 0.5) / 99) + ((rTerminal.GetLockLevel * GetRandomPercent) / 99)				if RandVal < GetActorValue Science			if GetRandomPercent < 10				set Hack_Outcome to 1			elseif				set Hack_Outcome to 0			endif		elseif			set Hack_Outcome to 0						if GetRandomPercent < 20				set Hack_Outcome to -1			endif		endif		if Hack_Outcome == -1 ; Locked Terminal. Crit. Failure.			rTerminal.lock 2			ShowMessage "Access Denied."		elseif Hack_Outcome == 0 ; Failure. No negative effects.			ShowMessage "Terminal locked. Contact administrator to unlock terminal."		elseif Hack_Outcome == 1 ; Success.			rTerminal.unlock			ShowMessage "You successfully hacked the terminal."		endif	else		; Perform the normal functions.		rTerminal.Activate	endif	End

Yep, because you're calling a function outside a block (set rTerminal to getContainer). For some reason they disabled error messages in the new GECK. Plus, GetContainer isn't going to do anything- terminals don't have storage, you can't add items to them. Is this script planned to go on a terminal? If so, you should be using getSelf to find its reference, not that you need to as object scripts assume a "self." before all functions unless you provide a different ref.

Also, getButtonPressed doesn't return a value until the frame after the player has pressed the button- Messagebox doesn't hold up scripts. It's used like:

begin onActivate   messageBox MyMenuBox   set Waiting to 1endifbegin gameModeif(Waiting)   set button to getButtonPressed   if(button > -1)      set Waiting to 0      ;Menu choices   endifendifend

Also, I'd really suggest going with the perk idea. Make a perk that adds an activate option, make that option "Auto-Hack Terminal", and write whatever script in the results script window of the perk, and it'll run on the terminal when the player selects that choice. You can specify conditions for the terminal (e.g. not lock level 0 or Needs Key) and the player to prevent it popping up unnecessarily. All you need to add the perk is make a quest scripted to do:

scn MyHackingQuestshort doOncebegin gamemodeif(doOnce)else   player.addPerk MyHackingPerk   set DoOnceto 0   stopQuest MyHackingQuestendifend

E: Just a note, the if(),else stuff in Bethscript is weird. If(var) acts as if(var !=0), but is faster. And going if(var), else is faster than if(var == 0).

The if(var) functionality isn't actually that weird. Many programming languages work like that - C, for example. It assumes a value of 0 is 'false' and any other value is 'true'. The fact that it's faster is a little odd - same with the if(var),else bit. The fact it works at all isn't weird, though.

I got everything to compile and save.

Now just to figure out why everything keeps crashing when I access a terminal. I did the perk/quest/script method.

From my most studious efforts of testing, I have found that the:
* Quest Portion Works
* The Perk is added successfully
* The Quest Finishes
* The Code Compiles.

I have also found that
* The whole game crashes if you attempt to access a terminal regardless if there's /ANY/ code attached to the perk. It just doesn't work at all.

In addition, I have not had any opportunity to even test the dialogue.

Okay. Dialogue works.

I found why it crashes.

I have "Run Immediately" checked in the perk menu.

I don't know why that's crashing or how to fix it other than have it make a button for me which I don't want it to do.

Future tip:

Don't use GameMode, Toaster.

Use Menumode otherwise the code will /NOT/ operate.

If you use OnActivate the terminal will also no longer be able to perform its default action.

Okay. That's all I've found out. That is this:

* OnActivate does not function in a script inside of a Perk.
* GameMode does not function in a script inside of a Perk.
* OnTrigger does not function in a script inside of a Perk.

* 'This' is not a replacement inside of a Perk.
* GetSelf does not function in a script inside of a perk.

* Menumode DOES function in a script inside of a Perk.

* The Radio box for "Run Immediately" will instantly crash a game when the perk is activated.

Edit: I answered my own question.

* The default reference ID for the script IS the target (In this case the Terminal)

I think I know why your script isn't working - the activation perk stuff works very differently from other scripts. The activation perk actually creates the message box and looks for the button press and everything by itself - the script that you plug into the box for the perk is what happens once you click on the button (and it only runs once). You don't use game mode blocks or anything like that. It's basically a result script, same as a dialogue result script.

That's exactly what's happening. That said, you can't even update variables because it's all in the same frame. So variables are completely useless. I'm thinking that's a bug with the game, and I was thinking about maybe bypassing it by creating an object with the actual hacking script on the "OnActivate" trigger.

Then in the perk entry I put Activate "Refid" "Terminal RefId".

Then I could maybe bypass the variable limit quickly enough by using this as a simulated call. I am so tired right now, so forgive me if everything I'm saying makes no sense.

In addition, because "Run Immediately" doesn't work as a flag, I can't run a script pre activation (Pre priority) to the main dialogue to set the global "TerminalDiff". Thus I can't do a check to make sure the player can even /ACTIVATE/ the terminal because of skill requirements.

So complications.

Which mode you use depends on where you're waiting for the response. If you open a message in gamemode, then it'll get the button result when the message's MenuMode finishes and it returns to gamemode.

MenuMode is a blocktype and a function- as a function it can be used to check for specific menu types. Blocks aren't meaningful inside result scripts, because the result script just runs once immediately when it's triggered.
GetSelf won't work because you can't declare variables in a result script, but it's unnecessary anyway as object & result scripts assume they'll run on whatever triggered them- the activated object for Perk result scripts, the NPC for package & dialogue result scripts, and so on. If you need variables in a result script, use globals or quest variables (e.g. set myQuest.Var to [whatever], then compare getrandompercent to myQuest.Var).

Yep, faux functions are a not entirely uncommon way of doing things if you need to use variables in ways you couldn't use them in result scripts- for example there's no way to use variables as arguments (i.e. player.additem MyQuest.Var doesn't work) other than globals, which don't support references. Your script could just be rejigged to use quest variables instead, though.

That's why you make auto-hack an activate choice, and you conditionalise that choice's display on the terminal lock level and the player's skill. Entirely hijacking the terminal activate behaviour's not going to work, and seems pretty insane when all you want to do is display a menu that's "Activate normally"/"Auto-hack" which is exactly what adding an activate choice would do.

No, but I wanted to do a 'run immediately' script to set a global variable with the locklevel of the terminal before execution.

I'm going to remove the blocktype and recompile to see if variables will set correctly.