This system will allow characters to keep a list of locations and targets that they may then view remotely from a Scrying Device or Teleport to.
Please read the documentation for setup and usage. *.erf contains all the required scripts. Sample module shows how the system works.
System is flexible and allows the builder to designate objects that are scying devices with different levels of power - some may provide travel and might even be set to certain locations.
Character's use a widget called the "scrying journal" to select locations and targets they wish to record for scrying later on. Other objects may allow that character to "learn" about a distant target and record that to their journal.
When scrying, the character takes control of a "Sensor" at the viewing location. Their body is still back at the device and may be interacted with - usually resulting in the session ending.
-------------
v.0.5 is the first released version but should still be considered beta. I have tested it just about as much as one person can mess with it. It should work for multi-player games without trouble.
-------------
v.0.6 Adds immunities to the "Sensor" while scrying. Now the scrying PC won't (shouldn't) be triggering traps or hit by AOE spells.
-------------
v.0.7 Adds a number of inventory and item related modifications, improved conversation options, and the option to allow a certain amount of communication to the scry location
This system is fully functional. The persistence process I have added below is supplemental to the Scry System.
5/2012 0.7.1 fixed a couple of small bugs.
..........
v.0.8.2 Hides and protects associates. Teleportation options. Improved Device Items that can move from module to module. Hopefully fixed a few other annoying bugs.
-------------
0.9 Combined Teleport conversation into Scry Conversation.
Added conversation elements to check for needed items and allow creation of Written Accounts of already Recorded Objects or Locations.
Adding copies of Associates, gave them conversation options
-------------
"scry_data" update adds persistence to the system. It is pretty down and dirty, but it works! Recorded Target lists are restored after resets/restarts. If non-unique targets are to be stored, the reset may return another object with the same tag. If you see any glaring errors, let me know - this is my first stab at a persistence script of my own.
Thanks!
Persistence Update. 5 scripts (3 edited, 2 new). To setup, wrap "scry_get_data" into your Module OnEnter event (or put it in a trigger or something so PCs will run the script). Add the variable INT "SCRY_PERSIST" = "1" to your module. This allows the persistence to be turned off if needed.
If you want the persistence to be campaign-wide (not tested) instead of module oriented, add the variable STR "Campaign" to your module with the name you want.
Oh - AND I think I found a good fix for the Associates who seem to like to tag along. They will also have copies that exist back at the scrying location. Let me know if you come across any problems. Thanks!
Just realized I uploaded this with an incomplete sample module - I was writing an actual story for the PC to use the system in... well, the scripts are all good. When the mod is finished, I will upload it.
Version 0.9 is here. Teleportation Conversation has been combined with the main conversation, so the "scrytele" convo is obsolete. Feel free to delete it. New in this version are "Written Accounts". These can be made by having access to ink and paper. The PC may enscribe a written Learning Item of any Object or Location they have in their journal. This will allow them to use the journal slots for new locations, but they just need to target the Written Account to relearn the old one.
Excited to upload this newest version. It provides a fix (though not perfect) for associates who would come along on Scrying events. These associates (familiars, henchmen, summoned creatures, animal companions, horses...) are now covered in the script. Also proud to announce Teleportation versions. See the "Helm of Teleportation" in the sample module.
Is that a pulse? Yes - I'm not dead. I have been working recently on a major issue with this system - familiars. Familiars seem to travel with the PC, so when they are scrying, there is the familiar merrily hanging around with them. I have a fix in the works and hope to post it soon - testing may take a bit.
Updated to 0.7.1 today, which has a couple of small bugfixes, including notifying the correct oTarget on a failed attempt to scry. Thanks for all the interest!
Posted by lordofworms at 2011-06-09 14:44:32 Voted 10.00 on 04/26/11
Thats is how I was doing it in nwnx2, and I had to remove the option to scry an item (bummer for now, but I wanted to start playing with it and so did my players so I figured we can always add it in later if we can find a way to track it down...
the problem (biggest) being that 90% of the time an item will be lost on server reset as its only 'safe' location are 'persistant' type containers that hold the contents in database and player character inventories...so this may be next to impossible, unless we just store the original object that holds the item and not the items location itself.
Inventory located objects add a wrinkle to what we were talking about. An object in another objects inventory seems to return an invalid or impossible location, so when looking for that item in a nearby inventory, it will not be found. I think I was able to add the GetNearest search into my GetData script. I will test it some more and see if I can touch up some other issues before I post it.
lordofworms, I thought about GetNearestObjectByTag but was unsure what I wanted it to be centered on -
GetNearestObjectByTag(sTag, oTarget, nNth) where oTarget is the center of the search, defaulting to OBJECT_SELF. In my bit, I only make a target object at the location if there is not a tag recorded, to keep down the number of objects created. I suppose if I make this object anyway, center the search from there and then destroy it after acquisition it should be okay. Is that similar to what you are doing in NWNx? Thanks for keeping this going.
Posted by lordofworms at 2011-06-03 05:22:44 Voted 10.00 on 04/26/11
I am using NWNx2 and for sametag creatures I just get two settings for each 'scry bindpoint', i store its tag, and its last location then on return(after reset) i use GetNearestObjectByTag with the stored location. so far its been working 100%, i know its a small chance I might get a different same tag object, but this lessens that chance.
@lordofworms - please feel free to modify as you need! Sorry I was out-of-touch for a bit but I did see your forum postings. My thoughts on the matter: I used local objects mainly to target moving objects iregardless of tag. You are right that I made this in a regular gaming enviroment. I think - for the most part - my update erf persistance will work in most situations, just not for targets that share a tag. I will mess around with it myself to see if there is a way to keep track of a non-unique target over resets.
Posted by lordofworms at 2011-05-18 08:12:08 Voted 10.00 on 04/26/11
I posted this on the Bioware social forums under scripting since I rather have a better persistant version...
Lightfoot made a very clear understanding of LocalObjects and how they are not the best to be used for any persistance on this thread which I thought I should post here for ref.
just so you know I am still looking into this..
if possible would it be ok to re-write alot of the store/save data code but use your design as a base? or would you prefer I create a new system..?
I would like to use yours because I like it very much but I dont want to 'take over' and step on your toes or anything...
Sorry for what looks like spamming myself with unfinished code. I added to the files section two sample scripts which would replace the store and get scripts for persistence. I do not know why they don't seem to work, but I may just be not writing them correctly.
The problems I had with the StoreCampaign and RetrieveCampaign seem to involve storing the journal correctly. While much simpler than what I ended up with these two scripts didn't seem to store and retrieve the object correctly
///////////storage script
void StoreData(object oPC)
{
string sCDKey = GetPCPublicCDKey(oPC)+GetName(oPC);
object oMod = GetModule();
string sMod = GetLocalString(oMod, "CAMPAIGN");
if(sMod=="") sMod = GetName(oMod);
object oLoc;
int nPersist = GetLocalInt(oMod, "SCRY_PERSIST");
object oJournal = GetItemPossessedBy(oPC, "scrywidget");
if(oJournal!=OBJECT_INVALID)
{
int nNth=1;
oLoc = GetLocalObject(oPC, "ScryLoc_"+IntToString(nNth));//get the first recorded target
while(nNth
The process in the scry_get_data script runs roughly like this:
It gets the entering object (oPC) and gathers information for the checking of data. It checks if the SCRY_PERSIST int is set on the module. If so it starts to look for stored data.
The first targets it looks for are if the scry location was a PC. If it was, it checks to see if that PC is in the current game. If they are, it records them into the entering PC's list. (this is the section I think you are refering to - it doesn't run the list check for all PCs, it is looking at those PCs online if the entering player had one in their list).
The Else section checks for game objects that would have been in the recorded list for the entering PC. If the target was an item or placeable, the location and the tag of the target was recorded and stored. This section reacquires that object. If there was no tag stored, then it was just a location and a marking object is created at that location and recorded in the PCs list.
Posted by lordofworms at 2011-05-08 13:28:50 Voted 10.00 on 04/26/11
p.s. store campaignobject and retrieve campaign object should work? if you could throw me the script that was giving you issues I could look at it and try and get it to work...seems easier then trying to store TAGs, resrefs, locations and all that...
Posted by lordofworms at 2011-05-08 13:26:30 Voted 10.00 on 04/26/11
ok ,looking at the scripts for the new persistance I can see I few things I might have done differently..but you said it was your first time, so really good job nontheless.
what I would change..
the OnEnter wrap...it seems to be a little complicated,more so then it should be...
basically when you trigger it, it checks first PC and then updates his list then continues for every player logged in, not horrible, but conditions such as
1) player A logs in and all is well.
2) player B logs in and now player A and player B also has his list auto updated...etc, so on so forth...not so good for a server running more than 1 player.
I would suggest this.
when one creates a scry point.
1) SetCampaign(object,location or however your doing it)
when one uses the scry object to actually utilize his scry points use a
2)GetCampaign on the OnConvo script
that way its only being populated when needed and not each time someone logs in/out.
if I am too vague let me know and I can write it out more clearly for you.
Posted by lordofworms at 2011-05-06 08:30:00 Voted 10.00 on 04/26/11
I am already using this in my live game.I just re-do my scry locations..which yeah kinda bums but hey, its still too cool not to!
looking into your code somewhat I see your SettingLocalObjects on the oPC. which yes, wont work for items even if we convert to storing the localobject on the item itself.
I am using NWNx and would glady work with you on this for an alternate version for persitence, dont remove your original as I am sure many single player campaigns can use this as is!
I will see about using your base mod and setting a nwnx version and get back to you soon..
If I could find a way to save the journal item persistantly, I could make the persistence work much better - right now, non-unique items may return the wrong item on reload. However, I seem to be clueless on how to properly save the object - StoreCampaignObject and RetrieveCampaignObject seem to do nothing for me. The scripts claim to store the object, but nothing is there to be retrieved. It may be that I am missing a step, or missing the process by which PW are saving inventory across resets. (NWNx? maybe) Any suggestions would be helpful. Thanks for trying this out!
lordofworms - I was re-reading your question and realized I didn't understand what you were asking about. My first shot at persistence is using a database write just after recording a new target. So every time one adds a new target, the script writes all of the targets recorded to the database. In your question, you talk about saving the recorded targets to the journal item - and that these keep the data even over resets - maybe skipping the need for database storage. I'm guess in your PW, the characters inventory is maintained across resets, and so the item would be - but variables on the PC are lost...
Sorry I am just a bit slow on the uptake and went a different route... thinking... Let me look at how the information is stored and get back to you.
I will see what I can do about the journal and database storage - It should be possible and strangely enough I was looking at persistance the other day. Glad you love the little touches!
Posted by lordofworms at 2011-05-01 16:43:43 Voted 10.00 on 04/26/11
Updated to v.0.7 - lordofworms, thanks for the spot in the documentation - I think that fix actually made it into this latest version.
Version 7 includes: communication options - allowing for the character to send a "thought" to the scry location for a certain period of time; Scry Devices in character inventories; Options in the conversation to record the scry devices or learning objects as targets; and improved animations (at least added some animations... whether they improve...).
Posted by lordofworms at 2011-04-26 08:32:16 Voted 10.00 on 04/26/11
excellent work in updating! I have since merged it with my own PW and it was pretty much plug and play after initial setup.
one thing of note.
in your README under setup
you have something like "to make a placeable scryable set "SCRyING_DEVICE" as an INT to 1"
this is wrong and should be..
"SCRY_DEVICE" INT set to 1
just FYI, in found it out by opening your module and looking since when I followed your steps in your README I was unable to converse with my 'scrying' placeable because of having the wrong variable INT name.
other than that, docs were simple and well written.
if I havent voted a 10 earlier, I have now.
Updated the scripts to v.0.6 today. When scrying, the "Sensor" (the actual PC) will have a number of immunities added to it. I guess the main issue is that if they have these immunities from some other source, those will be removed at the end of the process as well. I have been adding checks for removing only permanent duration effects, but that is not a complete solution.
On the familiar suggestion by Sethan - I will look at that - but it would mean adding a familiar to the PC (even if they are of a class not using familiars), possessing them, making the familiar immune to effects and transporting them... it might be cleaner though.
Thanks for the great comments! The primary issue is in the stage where a PC is working the main scry section. The Following script initiates the Cutscene concept lordofworms mentioned in the forum - which makes the PC "plot" and invulnerable. But when just scrying, currently the PC is just invisible and paralyzed. I am playing with adding Immunity to Spells and Immunity to Traps while scrying. This seems to work, but it may still be possible there are other forms of damage they may incur. I will post my current fix after a little more testing and continue playing with it.
Site
at 2013-04-09 16:29:40
at 2011-06-09 14:44:32
