The Merely Impossible Things

[Legacy_Lightfoot8]

               

Greyfort wrote...
 Funk and Light are right local vars dont stay '> 

I am not sure what you mean by this one.   Locals dont stay on what ?


As far as your DB method It sounds a lof like the one Knat put on the vault.   You may want to check it out.  If you use DMFI 1.09  NBDE is already a part of it, it just need to be activated in the module.

[NBDE] Natural Bioware Database Extension v1.0
               
               

               
            

[Legacy_Greyfort]

               Lightfoot wrote: *The real point here is that it is problematic to store LocalObjects onto items.  Yes they can be stored but the data is no good after a reset.  Since the stored Local Object can, after a server reset, Point to a completely different valid Object. The storing of local Objects onto items, should only be done with great care. If ever*



I was agreeing with you and funk on that issue, and so far the only way I know to restore any local vars(string,int,object,etc) is store them into DB and recall the DB at modload/ client ent to set the Local vars.  Did I explain that better?
               
               

               
            

[Legacy_Lightfoot8]

               Yes,  Thank you.
               
               

               
            

[Legacy_GhostOfGod]

               I thought the area IDs stayed the same so long as you did not add or alter areas in your module in the toolset and then "build" your module. Seems like one of the things we figured out through trial and error. So long as we did not alter the module we didn't have any issues with people returning to stored local areas on database items that the player carried even over resets. I could be wrong but that seemed to be the case for us.
               
               

               
            

[Legacy_Lightfoot8]

               You are correct Ghost,



Basicly every object in the game is given an ID#. The module is always ID 0.

The areas are added to the list next from the Module Info file.  Giving them ID's of 0-X

Where X is the number af areas you have in the module.

So as long as you do not change the module the areas should load to the same ID's every time.

This is at least what my tests have shown without looking at the machine code.
               
               

               
            

[Baaleos]

               With regards to Funky's concern above about whether nwnx_areas might cause complications, I dont think it is currently coded to re-use memory space that is deleted.



eg - Area made, Area Deleted, Area Made



The Areas are made at the end of the list I think, if they were made to fill in the gap's, then it might cause problems, but in a server instance, the local object id for areas should remain constant, or OBJECT_INVALID for cases where an area is deleted.



The only possible exception, I think, might occur, is if the last area in the list is deleted, then the Adding of a new area, might take its place, because from what I can remember, it does increase and decrease the area count, which might cause a newly added area, to get the area id of the previously deleted area.



Note - the order in which objects are created, also offsets object id's.

More areas = more id's that are used, and more creatures = more object id's
               
               

               
            

[Legacy_FunkySwerve]

               Wuhay too many posts on storing locations. To top it all off, I noticed on a reread of the thread that Baaleos actually DID mention location storage via string in his first reply.  '>

Anyway, in an effort to get the thread back on track, here's an old compilation of data-getting functions made by Sunjammer some years back, showing which don't work on certain objects (mostly GetResRef). It's out of date, now, since I think some now work that didn't back then, but many should remain accurate.

----------------|------|------|--------|-----
 Object         | Type | Name | ResRef | Tag 
----------------|------|------|--------|-----
 Module         | 0    | Y    | N      | Y
 Area           | 0    | Y    | N      | Y
 Player (PC)    | 1    | Y    | N      | N
 Creature       | 1    | Y    | Y      | Y
 Item           | 2    | Y    | Y      | Y
 Trigger        | 4    | Y    | Y      | Y
 Door           | 8    | Y    | N      | Y
 Area Of Effect | 16   | N    | N      | Y*
 Waypoint       | 32   | Y    | N      | Y
 Placeable      | 64   | Y    | Y      | Y
 Merchant       | 128  | Y    | N      | Y 
 Encounter      | 256  | Y    | N      | Y 
----------------|------|------|--------|-----
* an AOE is tagged with the LABEL column from vfx_persistent.2da

If someone wants to spend the time to update it, that'd be handy.

Funky
               
               

               
            

[Legacy_GhostOfGod]

               Hmmm. I'm sorry to keep going with the location thing. It's just that I'm confused i guess. The topic of this post has to do with things that are impossible in NWN script. And one of the things that was listed as impossible was:

Store a location on an item as local location

But of course we have the function "SetLocalLocation" which I use on items and it works fine.

So I guess I'm just asking if this is something that does not belong on this list of impossible things?

               
               

               
            

[Legacy_FunkySwerve]

               

GhostOfGod wrote...

Hmmm. I'm sorry to keep going with the location thing. It's just that I'm confused i guess. The topic of this post has to do with things that are impossible in NWN script. And one of the things that was listed as impossible was:
Store a location on an item as local location
But of course we have the function "SetLocalLocation" which I use on items and it works fine.
So I guess I'm just asking if this is something that does not belong on this list of impossible things?

My assumption is that she meant persisting across resets, or in the toolset.

Funky
               
               

               
            

[Legacy_Lightfoot8]

               The 'AssignCommand on a trigger' From the original post can also be done.   I Just finished testing it.  It worked fine.  
               
               

               
            

[Legacy_La Rose Noire]

               I had impossible things :



- Change or modify gender of something



- Possess anything else than a familiar



- Change name and race of familiar choosen by a PC

               
               

               
            

[Legacy_TheSpiritedLass]

               

La Rose Noire wrote...

I had impossible things :
- Change name ... of familiar choosen by a PC

SetName will work on familiars.  In the PW setting, it does NOT last across player relogs unless additional scripting is done.  I've done voice chat commands to change the names of familiars, animal companions, dominated creatures and summoned creatures.