41 réponses à ce sujet

[AND04]

Are "global" objects possible?

As far as i see it atm - it is like this:

Objects are bound to the area (or arealist) they are created in and you can't access them from anaother area (as the area istn't loaded).

Is there a possibility to generate global objects (e.g.: placeables) ?

Or Maybe move them to another area when you leave one? 

Or would this need something like creating a new area - placing the object there and adding the area via arealist to all areas that i want to use this object from?

[SilentCid]

When you create a new placeable you can find them all in your palette window-placeables. They are all global but if you want to run a specific script on some of them in a certain area then you need to create a tag name for each of those placeables. Another way would be simply creating a new placeable with a tag so can save yourself time instead.

[AND04]

i know all that ofc - problem is that the new placeable is a new object of the same type and has the same tag - but any changes made to the first object aren't on the 2nd as they are different objects - now this isn't a problem within an area - as i can access and move the object at will, but if i am in a different area than the object and i want to access is in i can't.

I am speaking from the scripting point of view here btw.

A very spezific task would be for example to open the party chest at warden's keep or the "New one" in the party camp from another area...

Modifié par AND04, 15 novembre 2009 - 06:07 .

[Phoatu]

Hey, on this matter i'm really not sure if i'm doing something wrong or not, but it seems that when you open the toolset there's supposed to be a _Global folder in the palette window.



For some reason i can't get the _Globals folder to appear in the palette window no matter what i do. I don't know if there's a setting that makes it invisible; but i've tried making my own module and even tried to go through the single player module.



There's no _Global folder, no area list, nothing.



Anyone know what might be going on? (it's a fresh install of the toolset and i haven't messed with any settings)

[Quildra]

I'm trying to do something similar to you... I think.

I haven't found a way to get an object to span multiple areas yet. but i am trying something with a pool object. although the docs aren't clear weather a pool object will be reset to its original state or not when deactivated.



I have an idea if you are trying to access one of the inventory chests though

You might be able to store an inventory list when leaving an area and populate the inventory list of a newly spawned chest.

[Sarcen]

I've attempted this aswell, without any luck, same issue, was trying to interact with a inventory from any zone. I've been thinking about alternate "hacky" methods, e.g. putting all the inventory inside the player inventory during transitions and then spawn a new chest (somewhere at -10000z) and move them back into the chest, but this way i would still need to be able to flag inventory items that belonged to the chest. not sure if that is possible... yet...

[Quildra]

you could use a combination of:

GetItemsInInventory which will return you an array of items held by an object.

and

GetItemsInInventory to add them back in to your new chest.

I've nearly finished my mod that will call a chest into existence near your players location so I may try this method out tomorrow to test how the inventory buffer could work.

[georage]

wouldn't the player be a global object?



the player should always be in the area you are concerned with, right?



Of course, GetModule() would be nice

[georage]

OK, it appears there IS a GetModule function! So, try that.



http://social.biowar...x.php/GetModule

[AND04]

hmm, storing the chest on the Module - now thats a thought - i'll try that tonight

[Proleric]

When scripting, objects are only visible if they're in the same area list as the player.

Otherwise, for example, GetObjectByTag will return OBJECT_INVALID.

One way of handling this is to use plot flags - on entry to an area, consult the plot settings and configure the objects accordingly. This is generally easier than definining local variables on the module or player (because the latter have to be pre-defined in the 2DA).

[Quildra]

Surely in this example it would be alot simpler to store the object as a local variable on the module using SetLocalObject than having to rebuild the object?

[Proleric]

Quildra wrote...

Surely in this example it would be alot simpler to store the object as a local variable on the module using SetLocalObject than having to rebuild the object?

What the Bioware devs have said in the past is that it's best to have one object instance in each area list. If you don't want the overhead of creating them, you can use the plot flags on entry to decide whether to make them visible or not.

It's no more work, just a matter of doing things the DA way.

I suspect the reason is that if you store the object as an object variable on the module while in area list A, move to area list B, then tell the engine to move the object, you are referring to an object which isn't loaded. The object variable is just a pointer to something that doesn't exist at that time.

Also, as previously mentioned, the local object value will not be set unless that local object is predefined in the module variable 2DA.

Modifié par Proleric1, 19 novembre 2009 - 11:20 .

[Quildra]

I'm not sure that is completely correct. there have been reports that GetObjectByTag will return a valid object even if you have left the area that object is in. I plan to test this tonight to confirm.

[Proleric]

In my tests, GetObjectByTag on an object in another area list returns OBJECT_INVALID.

Note "area list". If the object is in another area in the same area list, it's still valid, because everything in an area list is current.

The point Bioware made about this was that referring to objects in other area lists is unreliable, because it's not designed to work that way. So, even if it appears to work (and for me, it doesn't), it would be better not to do it.

Modifié par Proleric1, 19 novembre 2009 - 12:46 .

[Quildra]

hmmm if that holds then there doesn't seem to be a away to store a global object.

So we would have to re-build the object every time which is a bit annoying.

[Phoatu]

I appreciate the responses, but the way the Dragon Age toolset works is pretty foreign to the toolsets i've worked with in the past.



So i gather that the only way to be able to inspect/alter/etc existing objects is to go to an area where they're already existing...



How would i do this when creating a (blank) module which is to contain items to be put directly into the player's inventory?



Also, how would i do this if i can't even get the Area List to show properly (as far as i know) in the palette window, even when i've got the single player module open?



Sorry if i'm a bit green; but it's beyond what i understand so far :x

[Astorax]

Let's take a step back here...what exactly are you trying to do?



When a player starts a module, have them pre-equipped with a specific set of gear? That's what it sort of sounds like.

[Nodrak]

What you want is simple. You can Right click on any resource in the toolset, (and the same option is available when you create most of the resources too) go into properties, you will see:

Folder
Module
Owner

Folder is the 'location' of where that 'Designer Resource' is located in the SQL database your toolset is currently set to read. This is for organization and version control more then anything.  (As opposed to 'Art Resources' which are NOT stored in the databse, and are instead kept locally in raw and exported formats)

Module is where the 'scope' of the resource is located so to say. For example, items need the Module set to 'Core Game Resources' to be used outside of the module they were designed in. (The problem you are describing).

Owner is the module that has created or owns this resource. I am not sure of the exact purpose of this field is other then to have a reference for the origin of a resource for back- work.

You can also set this up for any scripts you make/edit. This is ground where you need to know what you are doing though, because if your script interacts with the core game rules or logic automatically, it will modify your game for all modules. As far as I understand, you can create a script, owned by your module, with the script's module set to Core Resources, and then you can call your script locall in your mod or any mod, so long as your Scripts Owner module is installed (enabled?).

I havn't delved into the testing of any of this, its just from my understanding of the structure.

It appears I have missunderstood you.  It appears you are trying to access a script attached to an object in an area, an area of which you are not present in.  What I described above may help, since the Warden's Keep is a seperate module from the 'Party Camp' area, but you would have to confirm that.  If the Storage Chest script is set to Module: Core Game Resources, you should be able to access its code, but if it stores the items in a local variable on the object, then I am not sure.. lol...

The premise being that you are basically calling the script that the chest uses, but you are bypassing the chest object because it is not able to be found/loaded outside of our area.  This will highly depend on the nature of the script you are trying to interface with and how it stores its information.

A solution that arises to my mind, is setup either a local variable in your module properties via 2da's and store your chest's inventory there (module wide), or store your chest's inventory in v-array in a script that is either Module wide or as above included for all modules.  I hope that was clear ><

Modifié par Nodrak, 20 novembre 2009 - 04:28 .

[Proleric]

Astorax wrote...

Let's take a step back here...what exactly are you trying to do?

When a player starts a module, have them pre-equipped with a specific set of gear? That's what it sort of sounds like.

Yes, that query seems to be about items, not placeables. At risk of going off-topic, the answer is in the second example of character generation in the wiki.
Back on topic, items are visible to scripts if the container is in the same area list as the player.

[Quildra]

Astorax wrote...

Let's take a step back here...what exactly are you trying to do?

When a player starts a module, have them pre-equipped with a specific set of gear? That's what it sort of sounds like.

I believe me and AND04 are both trying to create a away to access extra storage in AND04's case access the chest in wardens keep. In my case access a portable chest that the user summons.

See my thread here for more info on what I'm trying and how I'm going about it. 
So the main query is about placeables not items 

[Quildra]

Nodrak wrote...

What you want is simple. You can Right click on any resource in the toolset, (and the same option is available when you create most of the resources too) go into properties, you will see:

Folder
Module
Owner

Folder is the 'location' of where that 'Designer Resource' is located in the SQL database your toolset is currently set to read. This is for organization and version control more then anything.  (As opposed to 'Art Resources' which are NOT stored in the databse, and are instead kept locally in raw and exported formats)

Module is where the 'scope' of the resource is located so to say. For example, items need the Module set to 'Core Game Resources' to be used outside of the module they were designed in. (The problem you are describing).

Owner is the module that has created or owns this resource. I am not sure of the exact purpose of this field is other then to have a reference for the origin of a resource for back- work.

You can also set this up for any scripts you make/edit. This is ground where you need to know what you are doing though, because if your script interacts with the core game rules or logic automatically, it will modify your game for all modules. As far as I understand, you can create a script, owned by your module, with the script's module set to Core Resources, and then you can call your script locall in your mod or any mod, so long as your Scripts Owner module is installed (enabled?).

I havn't delved into the testing of any of this, its just from my understanding of the structure.

It appears I have missunderstood you.  It appears you are trying to access a script attached to an object in an area, an area of which you are not present in.  What I described above may help, since the Warden's Keep is a seperate module from the 'Party Camp' area, but you would have to confirm that.  If the Storage Chest script is set to Module: Core Game Resources, you should be able to access its code, but if it stores the items in a local variable on the object, then I am not sure.. lol...

The premise being that you are basically calling the script that the chest uses, but you are bypassing the chest object because it is not able to be found/loaded outside of our area.  This will highly depend on the nature of the script you are trying to interface with and how it stores its information.

A solution that arises to my mind, is setup either a local variable in your module properties via 2da's and store your chest's inventory there (module wide), or store your chest's inventory in v-array in a script that is either Module wide or as above included for all modules.  I hope that was clear ><

The only problem i can see with that plan is that the inventory is managed and accessed by the OpenInventory command which takes and object as it first parameter. so if we were in a different area we wouldnt be able to get the object we need to reference. 

[Nodrak]

Quildra wrote...

The only problem i can see with that plan is that the inventory is managed and accessed by the OpenInventory command which takes and object as it first parameter. so if we were in a different area we wouldnt be able to get the object we need to reference. 

I figured that chest inventories were similar to creature inventories, which is what I was refering to with local variables on the creature.  The solution I proposed is still valid, you can store 'global' variables by having a script that is setup to be a core resourse store them.  You could do this with a script from a chest if you desire to use all the existing inventory code, all you would have to do is parse the inventory of your object into a script, like was talked about before in the thread. 

[Quildra]

So your suggestion would be to manage the chests inventory my self as well as let the game handle it?

SO i should call GetItemsInInventory every time something is added to my chest and store it in an array within it script.



How exactly would I gain access to this array from an other script? as this functionality would have to be within my chest interaction script and i would have to re-fill the new chest from my spawning script. Both of these script currently belong to the Core Game Resources.

[Nodrak]

Working off the idea you want to inferface with an object via putting things in it's inventory (as opposed to something like a conversation, or alternative), you would then call a script when the player closed the inventory or when you wanted to 'remove' the chest, or even possibly on area exit.

This script would store the items from the inventory of the chest into an array defined in its script. You will probably have to 'include' (programming wise) your chest's script into your 'access' script unless you want to make them the same script (which is not a problem).

You could, for example, make a spell that would call into existance a Storage Chest just off to the side of the player's current location. This script would populate the inventory of this chest with any items stored in script (that we make). The player can then interact with it normally, and swap items, etc. The player then cast's the spell again, which calls the script, which parses the Storage Chest's inventory, and then removes the chest.

Should be easily doable in theory.  The existing inventory code would just be an interface for the player to manage what items to keep and what to store.  You could custom code it all if you wanted (via some menu system, or whatever you can think up).

Some pseudo code if you will:

Chest_Spell
{

array(items) script_inv;

if (spellcast & !chestout)
then spawn(chest);

if (spellcast & chestout)
then close(chest);

spawn(chest)
{
create chest;

if (chest)
then
{
chestout = true;
chest_inv = script_inv;
}

}

close(chest)
{
script_inv = chest_inv;
Destroy(chest);
chestout = false;
}

}

Modifié par Nodrak, 20 novembre 2009 - 03:11 .