Jump to content

DOWNLOAD MODS

Are you looking for something shiny for your load order? We have many exclusive mods and resources you won't find anywhere else. Start your search now...

LEARN MODDING

Ready to try your hand at making your own mod creations? Visit the Enclave, the original ES/FO modding school, and learn the tricks of the trade from veteran modders...

JOIN THE ALLIANCE

Membership is free and registering unlocks image galleries, project hosting, live chat, unlimited downloads, & more...

Why isn't part of this script working?


lonewolf_kai
 Share

Recommended Posts

I'm working on a script which most of it works, but two functions of it are not.  I can't figure out why.  I think it has to do with the FDForm variable I have in place.  The two problem areas are Button 1 (Follow) and Button 2 (Stay).  They refuse to work.  Any clues as to why that part won't work?

 

 

 

Here's the script:

scn 1SSCommandFrostDrakeScript

ref FrostDrake
ref FDHumanoid
ref FDSecond
short Button

Begin ScriptEffectStart

		Set FrostDrake to FDrakeRef
		Set FDHumanoid to FDHumanoidRef
		Set FDSecond to FDrakeSecondRef
		MessageBox "Interact with Dragon:", "Call Dragon", "Follow", "Stay", "Rest", "Wake", "Protect", "Break Combat", "Change Form", "Form Revert", "Return Home"

End

Begin ScriptEffectUpdate

		Set Button to GetButtonPressed
			If Button > -1
				If Button == 0
					FrostDrake.RemoveScriptPackage
					FrostDrake.MoveTo Player 0 0 3000
					Set FDForm to 1
				Elseif Button == 1
					If FrostDrake.IsSpellTarget 1SSMountRest
						Return
					Elseif FDForm == 1
						FrostDrake.AddScriptPackage 1SSMountFollowPlayer
					Elseif FDForm == 2
						FDHumanoid.RemoveScriptPackage
						FDHumanoid.AddScriptPackage 1SSFDHumanoidFollowPlayer
					Elseif FDForm == 3
						FDSecond.Disable
						FDSecond.MoveTo SSMountHomeMarker
						FrostDrake.MoveTo Player 0 0 1500
						FrostDrake.AddScriptPackage 1SSMountFollowPlayer
					Endif
				Elseif Button == 2
					If FDForm == 1
						Set FDForm to 3
						FrostDrake.RemoveScriptPackage
						FrostDrake.MoveTo SSMountHomeMarker
						FDSecond.MoveTo Player 0 0 3000
						FDSecond.Enable
						FDSecond.AddScriptPackage 1SSMountWander
					Elseif FDForm == 2
						FDHumanoid.RemoveScriptPackage
						FDHumanoid.AddScriptPackage 1SSMountWander
					Endif
				Elseif Button == 3
					FrostDrake.RemoveScriptPackage
					FrostDrake.AddSpell 1SSMountRest
				Elseif Button == 4
					FrostDrake.RemoveSpell 1SSMountRest
					FrostDrake.AddScriptPackage 1SSMountFollowPlayer
				Elseif Button == 5
					If FrostDrake.IsSpellTarget 1SSMountRest
						Return
					Else
						FrostDrake.AddScriptPackage 1SSMountFollowPlayer
					Endif
					addk1kcasterref.MoveTo FrostDrake 0 0 3
					addk1kcasterref.cast addk1kgetenemy FrostDrake
				Elseif Button == 6
					FrostDrake.Cast 1SSMountCalm FrostDrake
				Elseif Button == 7
					Set FDForm to 2
					FrostDrake.RemoveScriptPackage
					FrostDrake.MoveTo SSMountHomeMarker
					FDHumanoid.MoveTo Player 0 0 100
					FDHumanoid.Enable
					FDHumanoid.AddScriptPackage 1SSFDHumanoidFollowPlayer
				Elseif Button == 8
					Set FDForm to 1
					FDHumanoid.Disable
					FDHumanoid.MoveTo SSMountHomeMarker
					FrostDrake.MoveTo Player 0 0 500
					FrostDrake.AddScriptPackage 1SSMountFollowPlayer
				Elseif Button == 9
					If FDForm == 1
						FrostDrake.RemoveScriptPackage
						FrostDrake.Cast 1SSMountReturnHome FrostDrake
					Elseif FDForm == 2
						FDHumanoid.Disable
						FDHumanoid.MoveTo SSMountHomeMarker
					Elseif FDForm == 3
						FDSecond.Disable
						FDSecond.MoveTo SSMountHomeMarker
					Endif
				Endif
			Endif

End

Begin ScriptEffectFinish

End
Link to comment
Share on other sites

1. Magic effects DO NOT retain values of variables between casting of the spell. And each spell cast will contain its own set of variables.

 

2. Even though you have the code in the ScriptEffectUpdate event, it will only run once because the menu is only displayed once.

 

3. So the Variable FDForm does nothing for you. But since you are not assigning FDForm a variable type in your script, is it a global variable?

If its a global, than this part not applicable to the solution.

 

More information about the script is always good. If you suspect FDForm, then explain how its defined and how you want it used or what its used for.

Link to comment
Share on other sites

1. Magic effects DO NOT retain values of variables between casting of the spell. And each spell cast will contain its own set of variables.

 

2. Even though you have the code in the ScriptEffectUpdate event, it will only run once because the menu is only displayed once.

 

3. So the Variable FDForm does nothing for you. But since you are not assigning FDForm a variable type in your script, is it a global variable?

If its a global, than this part not applicable to the solution.

 

More information about the script is always good. If you suspect FDForm, then explain how its defined and how you want it used or what its used for.

 

Ahhh thanks WillieSea!!  I didn't realize that magic effects do not store variables so that would be the issue.  I also noticed I forgot to add the "short FDForm" at the begining of the script after the "short Button" part.  It's on the actual script in the CS, I just forgot to add it in the first post.

 

Hmm, could I add a quest script to keep track of the variable?  Or I guess I could just make a Global variable through the Gameplay menu?

 

EDIT:  I just tried the Global variable option via Gameplay menu and it worked.  Any advice on using that?  The CS Wiki suggested not using them.

Edited by lonewolf_kai
Link to comment
Share on other sites

The CS WIKI is written by bitter people that know nothing about programming. :lmao:

 

But really, there is NOTHING wrong with using a global variable in this instance. In fact, it would use less resources and be faster than using a quest script to keep track of your values.

I will always say that in 99% of cases, a global variable is better than setting up and using a quest to keep track of your values. Now, if you already are using a quest for something else, then it makes sense to use it to keep track of your variables in the quest. But a global variable is less overhead than a quest variable ALL the time.

 

Its also easier to use a global variable than it is a quest variable in your scripts. :yes:

Link to comment
Share on other sites

The CS WIKI is written by bitter people that know nothing about programming. :lmao:

 

But really, there is NOTHING wrong with using a global variable in this instance. In fact, it would use less resources and be faster than using a quest script to keep track of your values.

I will always say that in 99% of cases, a global variable is better than setting up and using a quest to keep track of your values. Now, if you already are using a quest for something else, then it makes sense to use it to keep track of your variables in the quest. But a global variable is less overhead than a quest variable ALL the time.

 

Its also easier to use a global variable than it is a quest variable in your scripts. :yes:

Thanks again Wlliesea!  The global variable has been working like a charm, and this has even given me some ideas to make some of my other mods more efficient.

Link to comment
Share on other sites

Ah, Willie, see what you've done? We bitter people who know nothing about programming (even those of us who don't write Wiki articles) have reasons for cautioning against globals, even though they are surely easier and more convenient to use in many cases than jumping through all the hoops to avoid them.

 

Kai, even though your mod may be more efficient, each global adds to system overhead, and is usually slower to access than a local variable as well. Before you start making changes to your other mods, I would recommend reading "Global Variables Are Bad" to get some idea of the reasons behind what the CS Wiki article and other bitter people advise. This article is fair and balanced, and also includes examples of when it is good, or acceptable, to use them. It may get a little technical for you in places, but at least give it a skim.

Edited by BrettM
Link to comment
Share on other sites

Actually Brett, it has been proven that globals are faster than quest variables in the "Oblivion and Skyrim engine". (Perhaps they are 'bad' in other languages and that is why people have a phobia about them.) When I was on the Bethsoft forum more, there was a discussion on this very topic. A person 'known' for stress testing the speed of different papyrus commands did some stress testing on global access speeds versus Quest variable access speeds.

The test results? Global access speeds were much faster than Quest access speeds.

 

But, since we are talking milliseconds, I fail to see any reason to even bring up 'overhead' costs unless you are manipulating hundreds or thousands of variables, which is going to be slow anyway.

 

So, its my opinion that the solution is to go the 'easy to use' path, since today's computers are not hindered by a micro-micro-second either way. A human would certainly not notice it. But the programmer would certainly notice it with the easier coding.

Link to comment
Share on other sites

I fully agree that programmer time is more valuable than machine time, and simpler code that doesn't jump through so many hoops saves that time as well. Both in creating the code and maintaining it.

 

My overhead concerns are more about the way in which the system has to store and manage global variables and the impact on memory and cpu time sucked up by the system in doing that as the number of globals grows. Though, again, in these days of multi-core CPUs and systems with multi-gig RAM, these concerns are no longer major.

 

However, my main objections to globals are the risks involved in possible name collisions, the exposure of information outside the bounds of the scripting system that actually needs it, and the chances of a scripter unintentionally changing his own global or clobbering it with a local.

 

If nothing else, one needs a good naming system to protect his globals, and non-professionals are unlikely to think about the possibility that some other scripter is also going to come up with a clever name like "AmountOfGold" or "Flag" for a global. They fall into the trap of thinking of a global as "MY global" when, in fact, globals belong to the world. That's their entire reason for existing. This can certainly lead to some nightmarish scenarios where users are reporting problems that you can't reproduce because you don't know that some other mod they use is hammering your global.

 

I understand the headache of using a quest script simply as a repository for information that you need to pass around among scripts, and I agree that this is best avoided. Yet, at the same time, I believe there are often other alternatives to using globals, such as using State blocks and having scripts directly interrogate and set the properties of other scripts or use their functions and events. These things are a little more complicated to set up than a global variable, but I feel that it is worth knowing how to do them and worth using those techniques whenever possible to keep information encapsulated within your scripting system instead of hanging it out there for every script in the system to monkey with.

 

It just feels like a cleaner, tighter way to do the job than making a "global" that really isn't global in the sense that any script in any mod might need to access it, like GameHour. If the information is of interest only within the mod and not to the world, it is private and should be kept within the mod if possible, even at the cost of jumping through a couple of minor hoops and incurring a little extra overhead.

 

Naturally, one shouldn't be fanatical about it to the point of making baroque constructions only for the purpose of avoiding a global. But I think that's a lot rarer than the opposite situation, where globals are used far too casually as the quick-and-easy solution that avoids any careful thinking about the logic of what one is trying to accomplish. Or to avoid the effort of learning something new.

 

Which is why I cringe a little when someone tosses out "oh, just use a global" as an answer to a problem when the person who receives the advice is not aware that there are any issues to be considered in following it. This might lead a new scripter into the habit of reaching for a global as a routine solution, which I do not consider a Good Thing. There are a lot of mods out there and a lot of mediocre coders, and I would prefer to keep my variables to myself. :)

 

But, that's just MHO and I'm sorry it seems to have turned into a long discourse. I didn't mean to start an argument. I just thought the opposing viewpoint should at least get a mention. :)

Link to comment
Share on other sites

You may be confusing how global variables work in a 'real' programming language compared to how they are handled in the Bethesda games.

 

1. Name collisions between mods is 'impossible'. Behind the scenes, the script is compiled and the 'form id' is used, which includes the dynamic hexadecimal two digit number associated with the mod as it is defined in the players load order. So you can never touch another mod from your mod. Even if you use the exact same name for the global.

 

2. No other mod can touch your global variable, it simply does not have access to it. Even if it was in a quest, you cannot access that variable from one mod, to another mod.

*In Skyrim, you can access other mods with special commands, but you must implicitly specify the mod and the variable. So there is no way to mess up another mods globals unless you really want to.

Link to comment
Share on other sites

That's fine, you mod the way you like and feel comfortable. :thumbup:

Now you know why (in the bethsoft game mods) I tell people to use a global variable. They are safe, reliable and easy to use.

I guess you have to think of them as 'Limited globals' since they are only a global for your 'mod', not the game engine.

 

But there are limitations...

Global variables can only be the 'float' type.

So, you cannot store an actor/object reference in a global. For that, you need a quest script.

Also, in your calculations, if a decimal is possible as a result of math, it will hold the decimal values so you can't say something like, if global = 1, since it could equal 1.015 or what-ever.

Link to comment
Share on other sites

The discussion isn't going to be much help to scripters in general, seeing that my concerns were misplaced in regards to Papyrus and the Beth games. :) It might benefit a few programmers like myself who are experienced with other languages but new to Papyrus and modding. And it might benefit a few who get their start with scripting and go on to more ambitious programming. That's about it.

Link to comment
Share on other sites

No need to defend yourself, Kai. I didn't mean to cast any stones in your direction, or disparage your scripting abilities. In fact, you probably know far, far more about Bethsoft scripting than I do, since I'm barely started with only a couple of scripts to my credit.

 

My only advantage, if it is an advantage, is having a broader knowledge of what you might call programming philosophy. And, as you can see, that led me into a trap that I had to be pulled from by Willie, with his extensive practical knowledge of this particular system. :)

Link to comment
Share on other sites

I am a 'programmer' for a job, and hobby, so I guess I am one of the lucky ones. Although sometimes it does not feel that way. :rofl:

 

I know a bit about the limitations of the game and scripting because I taught myself all of this when I wanted to mod Morrowind back in 2003. There were no tutorials of forums for the game as there are now. And many years of helping on the scripting forums for Oblivion, Fallout 3 and Skyrim. You pick up a few things here and there.

 

And, just so you don't think I am all-knowing, I make a fair share of mistakes... lol

And if this discussion helped 3 people, I call it a success and time well spent. :thumbup:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...