This is a simple example of a tag based teleport scroll which teleports you to the location of a waypoint.
The tag of the waypoint is stored on the item as a string variable.
The erf includes an item, waypoint, and one script.
The mod shows them all working.
Usually, variables are all removed from any store-bought items marked as infinite.
The example mod already has this fix implemented as well as merchants selling infinite amounts of the scrolls to show that it works. I am uploading the variable fix as a separate entry.
This was inspired by one of Nightshades scripts, here:
Link
UPDATE:
The scroll will now jump the character using the item and party members standing nearby, instead of all party members in the area.
The item var fix in the example mod has been updated to v. 2.0, which ensures that altered or previously owned items will not be reset to palette defaults by this script.
Posted by The Nightshade at 2012-05-24 20:15:30 Voted 10.00 on 05/24/12
Forgot to vote. _________________________ I Sir am a Shrubber, I make and arrange Shrubberies.
Posted by The Nightshade at 2012-05-24 20:15:10 Voted 10.00 on 05/24/12
Brilliant mate, I rather like the expansion on my rather simple idea. XD _________________________ I Sir am a Shrubber, I make and arrange Shrubberies.
@The_Krit
If anything, the new version has more sanity checks than it really needs. Since I expanded it, I'm uploading it as its own entry. In the meantime, the example mod contains the new system.
It should be entirely safe to use in any PW using nearly any system.
If you do see any bugs, let me know. It hasn't been extensively tested yet.
Sorry, I meant to mention this earlier, but I got sidetracked. With regards to:
"If you buy an item in one PW, and then portal to a new PW and sell items from your old home, this system will not try to destroy any items that do not exist in the current PW's palette."
This is false. The trick you are trying to use (checking for a ResRef equal to "") has not worked in ages. However, if you do change it so that the fix script is only run on infinite items, this will not be a problem.
When I get time, I'll see about updating it to only run the fix on infinite items purchased to ensure that it can never break anything. I'll also use The_Krits faster store check.
@The_Krit
I use the tag trick sometimes also.
I've never had an issue using the store fix with any items. It is possible that it could sometimes mess with a crafting system, but it would also be fairly easy to have it check for a crafting var on the item and not try to 'fix' it if it has a crafting variable.
The reason I tend to use variable based item scripts is because I can change the way the item acts on the fly from in game very easy. If someone wanted to have these items change their destination point after a certain point in a mod, they could just update the variable on the item.
It may also be worth noting that this system is designed with connected worlds in mind. If you buy an item in one PW, and then portal to a new PW and sell items from your old home, this system will not try to destroy any items that do not exist in the current PW's palette.
If you are willing to limit the destination waypoint's tag to 16 characters, you could avoid the problem with local variables and stores by encoding both the script name and the destination tag in the item's tag. (First expand your script name to 16 characters. Then you could make the first 16 characters of the item's tag be the script name and the up to 16 characters after that be the tag of the destination.) Standard tag-based scripting will ignore everything after the first 16 characters of the item's tag, and tags can be up to 32 characters long, so this is one trick for getting extra information to a tag-based script.
But if you want to keep the extra scripts for handling items bought from stores (which look like they could mess up buying items that have been crafted before being sold to a store, by the way), you probably should simplify the test for having been bought from a store. Instead of seeing if the item was acquired from the nearest store, see if it was acquired from a store:
if ( GetObjectType(oAcquiredFrom) == OBJECT_TYPE_STORE )
There probably are not many cases when you would see a difference between this and what you have, but checking the object type is more reliable (and less work for the computer) when, for example, there are multiple stores in an area.
You must be Logged In to post comments in this section.